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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document supplements IEEE Standard P802. 16-2004 [1] which shall be considered normative in its 
entirety, with exclusion of the Physical Layer (PHY) and profiles defined therein. 

The present document describes the supplemental data transport and radio control functions of the Data Link Control 
(DLC) of High PErformance Radio Metropolitan Area Network (HiperMAN) systems, which operate on frequencies 
below 11 GHz. A separate ETSI document, TS 102 177 [2], specifies the Physical (PHY). 

With permission of IEEE® (on file asBRAN32_5d009), portions of the present document are excerpted from IEEE 
Standard 802.16-2001 and IEEE Standard 802.16a-2003. 
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Scope 



The present document supplements IEEE Standard P802. 16-2004 [1], which defines the Data Link Control (DLC) and 
Physical (PHY) of metropolitan area network systems. The present document provides the supplemental DLC functions 
required for systems operating in frequencies below 1 1 GHz to support PMP and optionally Mesh network topologies. 
The physical characteristics of frequencies below 11 GHz, as well as the characteristics of the Broadband Wireless 
Access (BWA) market segments for which the present document is designed, result in an environment, where Line Of 
Sight (LOS) is not necessary, multipath may be severe and the physical medium may be lossy. 

The present document does not address the requirements and technical characteristics for conformance testing, nor the 
requirements for the applicable below 1 1 GHz PHY Layer. Those are covered in separate documents. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] IEEE P802.16-2004: "IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air 

Interface for Fixed Broadband Wireless Access Systems". 

[2] ETSI TS 102 177: "Broadband Radio Access Networks (BRAN); HIPERMAN; Physical (PHY) 

layer". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Adaptive Antenna System (AAS): system adaptively exploiting more than one antenna to improve the coverage and 
the system capacity 

NOTE: AAS-enabled in the context of a PMP BS denotes the implementation of AAS as defined. AAS-enabled 
in the context of a PMP SS denotes the ability to communicate with an AAS-enabled BS using the AAS 
specific mechanisms. Though a PMP SS may itself implement AAS as defined, this has no impact on the 
air interface and hence no specific differentiation is made. 

adaptive modulation: system's ability to communicate with another system using multiple burst profiles and a system's 
ability to subsequently communicate with multiple systems using different burst profiles 

ARQ Block: distinct unit of data that is carried on an ARQ-enabled connection 

NOTE: Such a unit is assigned a sequence number, and is managed as a distinct entity by the ARQ state 
machines. 
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bandwidth stealing: use, by a subscriber station operating on a grant per subscriber station basis, of a portion of the 
bandwidth allocated in response to a bandwidth request for a connection to send another bandwidth request rather than 
sending data 

NOTE: See also: grant per subscriber station. 

DC carrier: in an OFDM or OFDMA signal, the carrier whose frequency would be equal to the RF centre frequency of 
the station 

MeSH (MSH): network architecture, wherein systems are capable of forwarding traffic from and to multiple other 

systems 

RF centre frequency: centre of the frequency band in which a BS or SS is intended to transmit 

Rx/Tx Transition Gap (RTG): gap, used by TDD and H-FDD systems, between the uplink burst and the subsequent 
downlink burst 

NOTE: This gap allows time for the BS to switch from receive to transmit mode and SSs to switch from transmit 
to receive mode. During this gap, the BS and SS are not transmitting modulated data but simply allowing 
the BS transmitter carrier to ramp up, the Tx/Rx antenna switch to actuate, and the SS receiver sections to 
activate. 

SS Rx/Tx Gap (SSRTG): the minimum receive to transmit turnaround gap 

NOTE: SSRTG is measured from the time of the last sample of the received burst to the first sample of the 
transmitted burst, at the antenna port of the SS. 

SS Tx/Rx Gap (SSTTG): the minimum transmit to receive turnaround gap 

NOTE: SSTTG is measured from the time of the last sample of the transmitted burst to the first sample of the 
transmitted burst, at the antenna port of the SS. 

turbo decoding: iterative decoding, using soft inputs and soft outputs 

Tx/Rx Transition Gap (TTG): gap, used by TDD and H-FDD systems, between the downlink burst and the 
subsequent uplink burst 

NOTE: This gap allows time for the BS to switch from transmit to receive mode and SSs to switch from receive 
to transmit mode. During this gap, the BS and SS are not transmitting modulated data but simply allowing 
the BS transmitter carrier to ramp down, the Tx/Rx antenna switch to actuate, and the BS receiver section 
to activate. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

a Averaging parameter for CINR and RSSI computations 

RSSjg^ max Initial Ranging Max. Received Signal Strength at BS 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

A AS Adaptive Antenna System 

ARQ Automatic Repeat reQuest 

BS Base Station 

BTC Block Turbo Code 

BW Bandwidth 

BWA Broadband Wireless Access 

CID Connection IDentifier 

CINR Carrier to noise and INterference Ratio 

CSCF Centralized Scheduling ConFiguration 

CSCH Centralized SCHedule 
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CTC Convolutional Turbo Code 

DCD DL Channel Descriptor 

DIUC Downlink Interval Usage Code 

DL DownLink 

DLC Data Link Control 

DSA-RSP Dynamic Service Addition - ReSPonse 

DSCH Distributed SCHedule 

DSC-REQ Dynamic Service Change - REQuest 

DSC-RSP Dynamic Service Change - ReSPonse 

FDD Frequency Division Duplexing 

FPC Fast Power Control 

FWA Fixed Wireless Access 

HCS Header Check Sequence 

H-FDD Half-duplex FDD 

ID IDentifier 

IE Information Element 

Im Imaginary 

LOS Line Of Sight 

MAC Media Access Control 

msb most significant bit 

MSH MeSH 

NCFG Network ConFiGuration 

NENT Network ENTry 

OFDM Orthogonal Frequency Division Multiplexing 

OFDMA Orthogonal Frequency Division Multiple Access 

PHY PHYsical 

PKM Privacy Key Management 

PMP Point-to-MultiPoint 

Re Real 

REQ REQuest 

RNG RaNGing 

RSP ReSPonse 

RSSI Received Signal Strength Indicator 

RTG Receive/Transmit transition Gap 

SDU Service Data Unit 

SS Subscriber Station 

STC Space Time Coding 

TEK Traffic Encryption Key 

TLV Type Length Value 

TTG Transmit/receive Transition Gap 

UCD UL Channel Descriptor 

UDP User Datagram Protocol 

UIUC Uplink Interval Usage Code 

UL UpLink 



4 PDU formats 

4.1 MAC header type encodings 
4.1.1 Type encodings 

The Type field in the Generic MAC Header shall indicate the presence of subheaders and payload as shown in table 1 . 
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Table 1 : Type encodings 



Type bit 


Value 


#0 (Isb) 


Grant Management Subheader 
1 = present, = absent 
Shall be on DL 


#1 


Packing Subheader 
1 = present, = absent 


#2 


Fragmentation Subheader 
1 = present, = absent 


#3 


ARQ Extended Packing/Fragmentation Subheader 
1 = extended, = not extended 


#4 


ARQ Feedback Payload 
1 = present, = absent 


#5 (msb) 


IVIesh Subheader 

1 = present, = absent 



Four types of Subheaders may be present. The per-PDU subheaders (the Mesh subheader, the Fragmentation subheader 
and the Grant Management subheader) may be inserted in MAC PDUs immediately following the Generic MAC. If 
both the Fragmentation Subheader and Grant Management Subheader are indicated, the Grant Management Subheader 
shall come first. If the Mesh Subheader is indicated, it shall precede all other subheaders. 

4.1 .2 Header Check Sequence (HCS) encoding 

The transmitter shall calculate the HCS value for the first five octets of the cell header, and insert the result into the 
HCS field (the last octet of the MAC header). It shall be the remainder of the division (Modulo 2) by the generator 
polynomial g(D) = D^+D^+D+l of the polynomial D^ multiplied by the content of the header excluding the HCS field. 

EXAMPLE: [HT EC Type] = 0x80, BR = OxAAAA, CID = OxOFOF; HCS should then be set to OxD5. 



4.2 



MAC subheaders 



4.2.1 



Mesh subheader 



The Mesh subheader as shown in table 2 shall always immediately follow the generic MAC header when operating in 
mesh mode, but shall not be used when operating in PMP mode. 

Table 2: IVIesh subheader format 



Syntax 


Size 


Notes 


Mesh Subheader { 






Xmt Node Id 


16 bits 


Node Id of the originating mesh node. 


1 







4.2.2 ARQ feedback payload 

If the ARQ feedback payload bit in the MAC Header Type field (see table 1) is set, the ARQ Feedback Payload shall be 
transported. If packing is used, it shall be transported as the first packed payload. See clause 5.1.2. 
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4.2.3 Fragmentation subheader 

The fragmentation subheader is shown in table 3. 

Table 3: Fragmentation subheader format 



Syntax 


Size 


Notes 


Fragmentation Subheader () { 






Fragmentation Control (FC) 


2 bits 


Indicates the fragmentation state of the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


If (Type bit#3 (Extended Type) == 0) 




See table 1 . 


Fragmentation Sequence Number (FSN) 


3 bits 


Sequence number of the current SDU fragment. This 
field increments by one (modulo 8) for each fragment, 
including unfragmented SDUs. Applicable to 
connections where ARQ is not enabled. 


Else 






Block Sequence Number (SN) 


1 1 bits 


Sequence number of the first block in the current SDU 
or SDU fragment. This field increments by one 
(modulo 2 048) for each block. Applicable to 
connections where ARQ is enabled. 


Reserved 


3 bits 




} 







4.2.4 Packing sublneader 

When Packing is used, muhiple SDUs may be packed into a single MAC PDU. When packing variable-length MAC 
SDUs, the MAC precedes each one with a Packing subheader as shown in table 4. 

Table 4: Packing subheader format 



Syntax 


Size 


Notes 


Packing Subheader () { 






Fragmentation Control 


2 bits 


Indicates the fragmentation state of the payload: 

00 = no fragmentation 

01 = last fragment 

10 = first fragment 

1 1 = continuing (middle) fragment 


If (Type bit#3 == 0) 




See table 1 


Fragmentation Sequence Number 


3 bits 


Sequence number of the current SDU fragment. This 
field increments by one (modulo 8) for each fragment, 
including unfragmented SDUs. Applicable to 
connections where ARQ is not enabled. 


Else 






Block Sequence Number 


1 1 bits 


Sequence number of the first block in the current SDU 
fragment. This field increments by one (modulo 2 048) 
for each block. Applicable to connections where ARQ 
is enabled. 


Length 


1 1 bits 


The length in bytes of the IVIAC SDU or SDU fragment, 
including the length of the Packing Subheader. 


} 







4.3 MAC management messages 



TLVs within MAC Management messages shall be ordered as follows. Parameters for optional features shall occur after 
those listed for support of mandatory features. Features that are defined optional, but are mandated by the implemented 
System Profile, if any, shall be ordered as optional. Both mandatory and optional TLVs shall subsequently be 
sequenced in order of increasing Type value. Parameters with defined default values should be omitted if the desired 
value coincides with the default one. 
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When reporting parameters in MAC Management messages, service class names should not be used. 

4.3.1 Supplemental MAC management messages 

As shown in table 5, supplemental MAC management messages are defined to facilitate ARQ, channel measurements 
and mesh functionality. 

Table 5: MAC management messages 



Type 


Message 


Connection 


Description 


33 


ARQ-Feedback 


Basic 




34 


ARQ-Discard 


Basic 




35 


ARQ-Reset 


Basic 




36 


REP-REQ 


Basic 




37 


REP-RSP 


Basic 




38 


FPC 


Broadcast 




39 


MSH-NCFG 


Broadcast 




40 


MSH-NENT 


Basic 




41 


MSH-DSCH 


Broadcast 




42 


MSH-CSCH 


Broadcast 




43 


MSH-CSCF 


Broadcast 




44 


AAS-FBCK-REQ 


Basic 




45 


AAS-FBCK-RSP 


Basic 




46 


AAS Beam Select 


Basic 




47 


AAS BEAM REQ 


Basic 




48 


AAS BEAM RSP 


Basic 




49 to 255 


Reserved 







4.3.2 Type 1/3: DL/UL Channel Descriptor (DCD/UCD) message 

TLVs which may be included in the DCD message shall be limited to those listed in table 6. 

Table 6: DL Channel Descriptor TLVs 



Name 


Type 


Length 


Value 


Burst Profile 


1 


variable 


May appear more than once. The length is the number of bytes in 
the overall object, including embedded TLV items. See table 10. 


BSEIRP 


2 


2 


Signed in units of 1 dBm. 


TIG 


7 


1 


TTG (in PSs). See TS 102 177 [2]. 


RIG 


8 


1 


RTG (in PSs). See TS 102 177 [2]. 


'^^^IR.max 


9 


2 


Initial Ranging Max. Received Signal Strength at BS 
Signed in units of 1 dBm. Signed integer. 










Frame Duration Code 


14 


1 


The duration of the frame. The frame duration code 
values are specified in table 1 1 , in TS 1 02 1 77 [2]. 


Frame Number 


15 


3 


The number of the frame containing the DCD. 


MAG version 


18 


1 





Burst Profile encodings which may be included in the DCD message shall be limited those shown in table 7. 
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Table 7: DL burst profile TLVs 



Name 


Type 


Length 


Value 


FEC Code type 


150 


1 


= BPSK (CC) 1/2 11= 64QAM (BTC) 2/3 

1 = QPSK (RS+CC/CC) 1/2 12 = 64QAM (BTC) 5/6 

2 = QPSK (RS+CC/CC) 3/4 13 = QPSK (CTC) 1/2 

3 = 16QAM (RS+CC/CC) 1/2 14 = QPSK (CTC) 2/3 

4 = 16QAM (RS+CC/CC) 3/4 15 = QPSK (CTC) 3/4 

5 = 64QAM (RS+CC/CC) 2/3 16 = 16QAM (CTC) 1/2 

6 = 64QAM (RS+CC/CC) 3/4 17= 16QAM (CTC) 3/4 

7 = QPSK (BTC) 1/2 18 = 64QAM (CTC) 2/3 

8 = QPSK (BTC) 3/4 or 2/3 19 = 64QAM (CTC) 3/4 

9 = 1 6QAM (BTC) 3/5 20 to 55 = Reserved 

10 = 16QAM(BTC)4/5 


DlUC Mandatory Exit 
Threshold 


151 


1 


to 63. 75 dB. 

C/(N+I) at or below which this DlUC can no longer be used and at 

which a change to a more robust DlUC is required, in 0,25 dB 

units. 


DlUC Mandatory Entry 
Threshold 


152 


1 


to 63. 75 dB. 

The minimum C/(N+I) required to start using this DlUC when 

changing from a more robust DlUC is required, in 0,25 dB units. 


TCS_enable 


153 




= TCS diabled 

1 = TCS enabled 

2 to 255 = Reserved 



TLVs which may be included in the UCD message shall be limited to those listed in table 8. 

Table 8: UL Channel Descriptor TLVs 



Name 


Type 


Length 


Value 


Burst Profile 


1 


variable 


May appear more than once. The length is the number of bytes in 
the overall object, including embedded TLV items. See table 10. 


Frequency 


5 


4 


Uplink centre frequency (kHz). 


Contention-based 
Reservation Timeout 


2 


1 


Number of UL-MAPs to receive before contention- based 
reservation is attempted again for the same connection. 


Sub-channelized initial 
ranging 


18 


1 


Indicates whether sub-channelized initial ranging is supported 

= Not supported 

1 = Supported. 


Sub-channelization 
focused contention codes 


151 


1 


Number of contention codes (Cg^) that shall only be used to 

request a sub-channelized allocation. Default value 0. Allowed 
values to 8. 


Sub-channelized 
REQ-Region-Full 
Parameters 


150 


1 


Bits to 2 Number of subchannels used by each transmit 

opportunity 

when REQ Region-Full is allocated in subchannelization 

region, per the following enumeration: 

0: 1 Subchannel. 

1 : 2 Subchannels. 

2: 4 Subchannels. 

3: 8 Subchannels. 

4: 16 Subchannels. 

5 to 7: Shall not be used. 
Bits 3 to 7: Number of QFDM symbols used by each transmit 
opportunity when REQ Region-Full is allocated in 
subchannelization 
region. 



Burst Profile encodings which may be included in the UCD message shall be limited those shown in table 9. 



£75/ 



14 



ETSI TS 102 178 VI .2.1 (2005-01) 



Table 9: UL burst profile TLVs 



Name 


Type 


Length 


Value 


FEC Code type 


150 


1 


= BPSK (CC) 1/211= 64QAM (BTC) 2/3 

1 = QPSK (RS+CC/CC) 1/2 12 = 64QAM (BTC) 5/6 

2 = QPSK (RS+CC/CC) 3/4 13 = QPSK (CTC) 1/2 

3 = 16QAM (RS+CC/CC) 1/2 14 = QPSK (CTC) 2/3 

4 = 16QAM (RS+CC/CC) 3/4 15 = QPSK (CTC) 3/4 

5 = 64QAM (RS+CC/CC) 2/3 16 = 16QAM (CTC) 1/2 

6 = 64QAM (RS+CC/CC) 3/4 17= 16QAM (CTC) 3/4 

7 = QPSK (BTC) 1/2 18 = 64QAM (CTC) 2/3 

8 = QPSK (BTC) 3/4 or 2/3 19 = 64QAM (CTC) 3/4 

9 = 1 6QAM (BTC) 3/5 20 to 255 = Reserved 

10 = 16QAM(BTC)4/5 


Focused Contention Power Boost 


151 


1 


The power boost in dB of focused contention carriers. 
See TS 102 177 [2] for details. 



Table 10 defines the format of the Burst_Profile, which is used in both DCD and UCD messages. 

The Burst Profile is encoded with a Type of 1, an 8-bit length, and a 4-bit DIUC/UIUC which is associated with the 
Burst Profile and Thresholds. The DIUC/UIUC value is used in the DL-MAP respectively UL-MAP message to specify 
the Burst Profile to be used for a specific burst. 

Table 10: Burst profile format 



Syntax 


Size 


Notes 


DL/UL_Burst_Prof ile_format { 






Type = 1 


8 bits 




Length 


8 bits 




Reserved 


4 bits 


Shall be set to 0. 


DIUC / UIUC 


4 bits 




TLV encoded information 


variable 




} 







4.3.3 Type 2/3: DL-MAP / UL-MAP message 

The following formats shall be used in the DL-MAP and UL-MAP messages. 

4.3.3.1 DL-MAP PHY Synchronization Field 

The PHY Synchronization Field of the DL-MAP message shall have the format shown in table 11. 

Table 1 1 : PHY synchronization field 



Syntax 


Size 


Notes 


Synchronization_f ield { 












} 







Frame number: 

• The modulo 2^^ frame number is increased by one every frame. 
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4.3.3.2 DL-MAP IE format 

DL-MAP Information Elements shall have the format shown in table 12. 

Table 12: DL-MAP information element 



Syntax 


Size 


Notes 


DL-MAP_information_element { 






CID 


16 bits 




DIUC 


4 bits 




Preamble present 


1 bit 


= not present, 1 = present 
if DIUC == 15 and not Extended 
DIUC = 3, shall be 


Start Time 


1 1 bits 




if (DIUC == 15) 






Extended DIUC dependent IE 


variable 


Report lEQorAAS DL lEQorSTC IE{) 


Padding nibble, if needed 


4 bits 


Completing to nearest byte 


} 







Connection Identifier (CID): 

• Represents the assignment of the IE to a broadcast, multicast, or unicast address. 
Downlink Interval Usage Code (DIUC): 

• A four -bit Downlink Interval Usage Code (DIUC) shall be used to define the burst type associated with that 
time interval. Burst Descriptor shall be included into DCD Message for each DIUC used in the DL-MAP 
except those associated with Gap, End of Map and Extended. The DIUC shall be one of the values defined in 
table 13. 

Preamble present: 

• If set, the indicated burst shall start with the short preamble. 
Start Time: 

• Indicates the start time, in units of symbol duration, relative to the beginning of the frame. The end of the last 
allocated burst is indicated by allocating a NULL burst (DIUC = 14) with zero duration. The time instants 
indicated by the Start Time values are the transmission times of the first symbol of the burst including 
preamble. 

4.3.3.2.1 DIUC allocations 

Table 13 contains the DIUC values used in DL-MAP_IE(). 

Table 13: OFDM DIUC values 



DIUC 


Usage 





SIC zone 


1 toll 


Burst Profiles 


12 


Reserved 


13 


Gap 


14 


End of IVIap 


15 


Extended DIUC 



4.3.3.2.2 



Channel measurement DL-MAP IE format 



The BS may use the DL-MAP Channel measurement IE to request a channel measurement report. The IE shall be 
followed by the End of Map IE (DIUC = 14). 
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Table 14: Channel measurement Information Element format 



Syntax 


Size 


Notes 


Report_Information__Element ( ) { 






extended DIUC code 


4 bits 


Channel measurement = 0x0 


Length 


4 bits 


Length = 0x1 


Channel Nr 


8 bits 


Channel number. 

Shall be set to 0x00 for licensed bands 


} 







4.3.3.2.3 



DL-MAP AAS IE format 



Within a frame, the switch from non-AAS to AAS -enabled traffic is marked by using the extended DIUC =15 with the 
AAS_IE() shown in table 15 to indicate that the subsequent allocations, until the start of the first UL-MAP allocation 
using TDD, and until the end of the frame using FDD, shall be for AAS traffic. When used, the CID in the 
DL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short preamble. 

Table 15: AAS DL Information Element format 



Syntax 


Size 


Notes 


AAS_DL_Information_element ( ) { 






extended DIUC 


4 bits 


AAS = 0x2 


Length 


4 bits 


Length = 0x0 


} 







4.3.3.2.4 



DL-MAP SIC IE format 



In the DL-MAP, an STC enabled BS may transmit DIUC = 15 with the STC_IE() shown in table 16 to indicate that the 
subsequent allocations shall be STC encoded. No preceding DL allocations shall be STC encoded and all subsequent 
DL allocations until the end of the frame shall be STC encoded. After this allocation, the BS shall transmit from both its 
antennas until the end of the frame. The first DL allocation following the STC_IE shall contain a preamble. The number 
of OFDM data symbols between two preambles and the number of OFDM data symbols between the last preamble and 
the end of the DL subframe must be even. 

Table 16: STC Information Element format 



Syntax 


Size 


Notes 


STC_Information_element { 






extended DIUC code 


4 bits 


STC= 0x4 


Length 


4 bits 


Length = 0x0 


} 







4.3.3.2.5 



DL-MAP DUMMY IE format 



A SS shall be able to decode the DL-MAP DUMMY IE for forward compatibility. A BS shall not transmit this IE 
(unless under test). A SS may skip decoding DL bursts scheduled after the Start Time of this IE within the current 
frame. 

Table 17: DL-MAP DUMMY Information Element format 



Syntax 


Size 


Notes 


DUMMY_Inf ormation_element { 






extended DIUC 


4 bits 


0x5 to OxF 


Length 


4 bits 


0to15 


Unspecified data 


Length x 8 bits 




} 
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4.3.3.3 



UL-MAP IE format 



The UL-MAP Information Element defines the physical parameters and the start time for UL PHY bursts. The format of 
UL-MAP elements is shown in table 18. 

When sub-channelization is active (see clause 4.3.3.3.4), UIUC 3 shall not be used. 

Table 18: OFDM UL-MAP Information Element format 



Syntax 


Size 


Notes 


UL-MAP_inf ormation_element ( ) { 






CID 


16 bits 




Start Time 


1 1 bits 




Sub-channel Index 


5 bits 




UIUC 


4bits 




Duration 


10 bits 




Midamble repetition interval 


2 bits 


ObOO = Preamble only 

ObOl = Midambles after every 8 data symbols 
OblO = IVIidambles after every 16 data symbols 
Ob1 1 = IVIidambles after every 32 data symbols 


if (UIUC == 4) 






Focused_contention_IE () 


16 bits 




if (UIUC == 13) 






Subchannelized„Network__Entry_IE ( ) 


12 bits 




if (UIUC == 15) 






Extended UIUC dependent IE 


Variable 




} 






Padding nibble 


0/4 bits 


Shall be set to 0x0 


} 







Connection Identifier (CID): 

• Represents the assignment of the IE to a unicast, multicast, or broadcast address. When specifically addressed 
to allocate a bandwidth grant, the CID may be either the Basic CID of the SS or a Traffic CID for one of the 
connections of the SS. 

Uplink Interval Usage Code (UIUC): 

• Shall be used to define the type of uplink access and the burst type associated with that access. A Burst 
Descriptor shall be included into an UCD message for each Uplink Interval Usage Code that is to be used in 
the UL-MAP. The UIUC shall be one of the values defined in table 19. 

Start Time: 

• Indicates the start time, in units of symbol duration, relative to the Allocation Start Time given in the UL-MAP 
message. For non-sub-channelized allocations, the duration of the burst is indicated as the difference between 
the start times of current and next map elements. The end of the last allocated burst is indicated by allocating a 
NULL burst (CID = and UIUC = 14). The time instant indicated by the Start Time value is the start of the 
transmission of the preamble. 

Duration: 

• Indicates the duration, in units of OFDM symbols, of the sub-channelized allocation. The duration is inclusive 
of the preamble and the midambles contained in the allocation. 

Sub-channel Index: 

• See table 1 . 
Midamble repetition interval: 

• Indicates the preamble repetition interval in OFDM symbols. 
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4.3.3.3.1 UIUC allocations 

Table 19 contains the UIUC values used in the UL-MAP_IE(). 



Table 19: UIUC values 



UIUC 


Usage 





Reserved 


1 


initial ranging 


2 


REQ Region Full 


3 


REQ Region Focused 


4 


Focused Contention IE 


5 to 12 


Burst Profiles 


13 


Gap 


14 


End of IVIap 


15 


Extended UIUC 



4.3.3.3.2 



UL-MAP focused contention IE format 



Table 20 defines the UL-MAP IE for allocation Bandwidth (BW) for a SS that requested bandwidth using Focused 
Contention Reservation Requests. This UL-MAP IE is identified by UIUC = 4 (see table 19). A SS responding to a 
bandwidth allocation using the Focused Contention IE shall start its burst with a short preamble (see clause 5.6) and use 
only the most robust mandatory burst profile in that burst. 

Table 20: Focused contention Information Element format 



Syntax 


Size 


Notes 


Focused_Contention_IE ( ) { 






Frame number Index 


4 bits 




Transmit Opportunity Index 


3 bits 




Contention Channel Index 


6 bits 




Contention Code Index 


3 bits 




} 







Transmit Opportunity Index: 

• Index number of the Transmit Opportunity that was used in the Bandwidth Request, which this message is 
responding to. Focused Contention Reservation Requests Transmit Opportunities are numbered from 63 to 0, 
starting from the beginning of the frame where the UL-MAP is transmitted. 

Contention Channel Index: 

• Index number of the Contention Channel that was used in the Bandwidth Request, which this message is 
responding to. 

Contention Code Index: 

• Index number of the Contention Code that was used in the Bandwidth Request, which this message is 
responding to. 



4.3.3.3.3 



UL-MAP AAS IE format 



Within a frame, indication of AAS-enabled traffic is marked by using the extended UIUC = 15 with the AAS_IE() 
shown in table 21 to indicate that the subsequent allocations be for AAS traffic. When used, the CID in the 
UL-MAP_IE() shall be set to the broadcast CID. Subsequent AAS PHY bursts shall all start with the short preamble. 
Stations not supporting the AAS functionality may treat the AAS_IE as a start of gap. The AAS_IE() shall not be used 
in AAS private map messages. 
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Table 21 : AAS UL IE format 



Syntax 


Size 


Notes 


AAS_Information_element ( ) { 






extended UIUC code 


4 bits 


AAS = 0x02 


Length 


4 bits 


Length = 0x0 


} 







4.3.3.3.4 UL-MAP sub-channelization IE format 

Within a frame, the BS may allocate a portion of the UL allocations to sub-channelized traffic. 

Table 22: Sub-channelization IE format 



Syntax 


Size 


Notes 


Sub-channelization_Inf ormation_element () { 






extended UIUC code 


4 bits 


Sub-cliannelization = 0x03 


Length 


4 bits 


Length = 0x2 


Length of Allocations 


16 bits 




} 







Length of allocations 

• The number of bytes, following the sub-channelization_IE, that are used to define sub-channelized allocations. 
A SS not capable of using sub-channelization may skip interpreting this number of bytes in the UL-MAP. 



4.3.3.3.5 



UL-MAP DUMMY IE format 



An SS shall be able to decode the UL-MAP DUMMY IE for forward compatibility. A BS shall not transmit this IE 
(unless under test). 

Table 23: UL-MAP DUMMY Information Element format 



Syntax 


Size 


Notes 


DUMMY_Information_element { 






extended UIUC 


4 bits 


0x4 to OxF 


Length 


4 bits 


Oto 15 


Unspecified data 


Length x 8 bits 




} 







4.3.4 Type 4/5: RaNGing REQuest/ReSPonse (RNG-REQ/RSP) message 

In addition to the TLVs listed in IEEE P802.16-2004 [1], the following TLVs are defined. 



4.3.4.1 



AAS Support 



To indicate whether it can receive broadcast transmissions, an AAS-enabled SS may include the following TLV in 
RNG-REQ messages: 



AAS Broadcast CapabiUty. 



Table 24: Supplemental RNG-REQ TLVs 



Name 


Type 


Length 


Value 


AAS broadcast capability 


4 


1 


= SS can receive broadcast messages. 

1 = SS cannot receive broadcast messages. 
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To indicate whether an SS, which set the AAS Broadcast Capability, may issue contention-based BW requests, an 
AAS-enabled BS may use the following TLV in RNG-RSP messages: 

• AAS Broadcast Permission. 

The following RNG-RSP TLVs may be sent by the BS to indicate the reception of an undecodable initial ranging 
(RNG-REQ) attempt or to indicate the reception of a sub-channelized initial ranging attempt. 

• Frame Number: 

Initial Ranging Opportunity Number. 

Table 25: Supplemental RNG-RSP TLVs 



Name 


Type 


Length 


Value 


Timing Adjust 


1 


4 


Tx timing offset adjustment (signed 32-bit). The time by 
which to advance SS transmission so that frames arrive at 
the expected time instance at the BS. 
See TS 102 177 [2], clause 14 for unit definition. 


AAS broadcast permission 


11 


1 


= SS may issue in contention-based BW requests. 

1 = SS may not issue in contention-based BW requests 


Frame Number 


12 


3 


Frame number in which the undecodable initial ranging or 
sub-channelized initial ranging attempt was detected by 
the BS. Usage is mutually exclusive with SS MAC 
Address. The opportunity within the frame is assumed to 
be 1 (the first) if the Initial Ranging Opportunity Number 
field is not supplied. 


Initial Ranging Opportunity Number 


13 


1 


Initial Ranging opportunity (1 to 255) in which the 
undecodable initial ranging or sub-channelized initial 
ranging attempt was detected by the BS. Usage is 
mutually exclusive with SS MAC Address. 



4.3.4.2 



Power management support 



Table 26: TLVs for power management 



Name 


Type (1 byte) 


Length 


Value (Variable Length) 


Power level Adjust 


2 


1 


Tx Power offset adjustment (signed 8-bit, 0,25 dB units). 
Specifies the relative change in transmission power level that the 
SS is to make in order that transmissions arrive at the BS at the 
desired power. 

When sub-channelization is employed, The subscriber shall 
interpret the power offset adjustment as a required change to the 
transmitted power density. 



4.3.5 Type 6: REGistration-REQuest (REG-REQ) message 

In PMP mode during Registration, the SS shall generate REG-REQ messages including the following parameter in 
addition to those specified in IEEE P802. 16-2004 [1]: 

• MAC Version. 

• Maximum transmit power. 

• Amplifier backoffs. 

• Current transmitted power. 

The transmitted power parameters are defined in table 27. 
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Table 27: Transmitted power parameters 



Name 


Type 
(1 byte) 


Length 


Value 
(variable length) 


Scope 


Maximum Tx power 


5.23 


1 


Achievable transmit power (peak) signed, 
0,5 dB increments. 




Amplifier bacl<offs 


5.24 


3 


Byte 0: QPSK 

Byte1:16QAM 

Byte 2: 64QAM (report as 0x0 if not 

supported). Backoff values in 0,25 dB 

increments. 




Current Tx power 


5.25 


1 


Current transmit power (peak) signed. 
0,5 dB increments. 





In Mesh mode during Registration, the Candidate Node shall generate REG-REQ messages including the following 
parameters: 

• SS MAC Address. 

• MAC Version: 

The MAC version implemented in the Candidate Node. 

• HMAC Tuple: 

Message digest calculated using HMAC_KEY_U. 
Both in PMP and Mesh mode, the REG-REQ may in addition contain the following parameters: 

• IP Version. 

• SS Capabilities Encodings. 

• Vendor ID Encoding. 

4.3.6 Type 7: REGistration-ReSPonse (REG-RSP) message 

In Mesh mode during Registration, the Registration Node shall generate REG-RSP messages including the following 
parameters: 

• Node ID. 

• MAC Version: 

MAC Version used in the network. 

• HMAC Tuple: 

Message digest calculated using HMAC_KEY_D. 
In Mesh mode, the REG-RSP may in addition contain the following parameters: 

• IP Version. 

• SS Capabilities Encodings: 

Capabihties returned in the REG-RSP shall not be set to require greater capabihty of the Node than is 
reported in the REG-REQ. 

• Vendor Specific Extensions. 
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4.3.7 Type 9/10: Privacy Key Management (PKM-REQ/RSP) messages 

In Mesh mode, the Authorization reply attributes and the Key request attributes listed in tables 28 and 29 shall be used. 
The HMAC-Digest's authentication key is derived from the Authorization key or the Operator Shared Secret. 

Table 28: Authorization Reply attributes 



Attribute 


Contents 


Operator Shared Secret 


Key l<nown to all nodes 


Key-Sequence-Number 


Operator Shared Secret's sequence number 


Key-Lifetime 


Operator Shared Secret's active lifetime 



Table 29: Key Request attributes 



Attribute 


Contents 


SS Certificate 


X.509 Certificate of the node 


SAID 


SA Identifier 


HMAC-Digest 


HMAC using HMAC KEY S 



4.3.8 Type 12: Dynamic Service Addition-ReSPonse (DSA-RSP) 

No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSA-RSP. 

4.3.9 Type 13: Dynamic Service Addition-ACKnowledgement (DSA-ACK) 

No TLVs besides HMAC Tuples shall be reported back in DSA-ACK messages. 

4.3.1 Type 1 4: Dynamic Service CInange-REQuest (DSC-REQ) 

DSC-REQ messages shall not contain Request/Transmission Policy, Fixed vs. Variable Length SDU Indicator, SDU 
Size, ATM Switching, or Convergence Sublayer Specification TLVs. 

4.3.1 1 Type 1 5: Dynamic Service CInange-ReSPonse (DSC-RSP) 

No TLVs besides Error Encodings and HMAC Tuples shall be reported back in DSC-RSP. 

4.3.12 Type 26/27: SS Basic Capability-REQuest/ReSPonse 
(SBC-REQ/RSP) 

The following Physical Parameter encodings shall be available for use with SBC-REQ and SBC-RSP. The Physical 
Parameters listed in IEEE P802. 16-2004 [1] shall not be used. 



4.3.12.1 



OFDM demodulator 



This field indicates the different demodulator options supported by a SS for DL reception. A bit value of indicates 
"not supported" while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


5.12.28 


1 


bit#0 640AM 


SBC-REO 






bit#1 Reserved. Set to 


SBC-RSP 






bit#2 CTC 








bit#3 SIC 








bit#4 AAS 








bit#5 to 7 Reserved. Set to 
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4.3.12.2 



OFDM modulator 



This field indicates the different modulator options supported by a SS for UL transmission. A bit value of indicates 
"not supported" while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


5.12.29 


1 


bit#0 64QAM 


SBC-REQ 






bit#1 Reserved. Set to 


SBC-RSP 






bit#2 CTC 








bit#3 Sub-channelization 








bit#4 Focused contention BW request 








bit#5-7 Reserved. Set to 





4.3.1 2.3 Subscriber transition gaps 

This field indicates the transition speed SSTTG and SSRTG for TDD and H-FDD SSs. 



Type 


Length 


Value 


Scope 


5.12.30 


2 


Bit #0 to 7: SSTTG (|js) 
Bit#8to15:SSRTG(|Js) 
Allowed values: TDD: to 50 |js; H-FDD: to 100 |js 


SBC-REQ 
SBC-RSP 



4.3.12.4 Bandwidth allocation support 

This field indicates the different BW allocation options supported by a SS. A bit value of indicates "not supported" 
while 1 indicates "supported". 



Type 


Length 


Value 


Scope 


5.15 


1 


bit #0: Reserved. Set to 


SBC-REQ 






bit#1 = 0: Half-Duplex 


SBC-RSP 






bit#1 = 1: Full-Duplex 








bit #2-7: reserved; shall be set to zero 





4.3.13 Type 33: ARQ Feedback message 

A system supporting ARQ shall be able to receive and process the ARQ Feedback message. 

The ARQ Feedback message, as shown in table 30, can be used to signal any combination of different ARQ ACKs 
(cumulative, selective, selective with cumulative). The message shall be sent on the appropriate basic management 
connection. 

Table 30: ARQ Feedback message format 



Syntax 


Size 


Notes 


ARQ_Feedback_Message_Format ( ) { 






Management Message Type = 33 


8 bits 




ARQ_Feedback„Payload 


variable 


See table 60. 


} 







ARQ Feedback information shall be either sent using this ARQ Feedback message or by packing the 
ARQ_Feedback_Payload as described in clause 5.1.2. 

4.3.14 Type 34: ARQ_Discard message 

This message is applicable to ARQ-enabled connections only. 

The transmitter sends this message when it wants to skip a certain number of ARQ blocks. The ARQ Discard message 
shown in table 3 1 shall be sent as a MAC management message on the basic management connection of the appropriate 
direction. 
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Table 31 : ARQ Discard message format 



Syntax 


Size 


Notes 


ARQ_Discard_Message_Format { 






Management Message Type = 34 


8 bits 




Connection ID 


16 bits 


Applicable CID. 


Reserved 


5 bits 




Block Sequence Number 


1 1 bits 


Sequence number of the last block in the transmission 
window to be discarded. 


1 







4.3.15 Type 35: ARQ_Reset message 

This message is applicable to ARQ-enabled connections only. 

The transmitter or the receiver may send this message. The message is used in a three-part dialog to reset the parent 
connection's ARQ transmitter and receiver state machines. The ARQ Reset message, as shown in table 32, shall be sent 
as a MAC management message on the basic management connection of the appropriate direction. 

Table 32: ARQ_Reset message format 



Syntax 


Size 


Notes 


ARQ_Reset_Message_Format { 






Management Message Type = 36 


8 bits 




Connection ID 


16 bits 


Applicable CID 


Type 


2 bits 


00 = Original Message from Initiator 

01 = Acknowledgement from Responder 

10 = Confirmation from Initiator 

1 1 = Reserved 


Reserved 


6 bits 




1 







4.3.1 6 Type 36/37: Report-Request (REP-REQ/RSP) message 

The Report Request message, shown in table 33, shall be used by the BS to request RSSI and CINR channel 
measurement reports. 

Table 33: REP-REQ message format 



Syntax 


Size 


Notes 


Report_Request_Message_Format () { 






Management Message Type = 36 


8 bits 




Report Request TLV 


variable 




1 







The Report Request TLV shall have the format shown in table 34. 

Table 34: Report Request TLV 



Name 


Type 


Length 


Value 


Report Request 


1 


Variable 
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Name 


Type 


Length 


Value 


Report Type 


1.1 


1 


Bit #0 Reserved, shall be set to 

bit#1 1 = Include CINR report 

bit #2 1 = Include RSSI report 

bit #3 to 6 Qgyg in multiples of 1/32 (range [1/32, 16/32]) 

See TS 102 177 [2], clause 10.2 
bit #7 1 = Report background noise 



When bit#7 is set, bit#l shall be and bit#2 shall be 1. The response shall contain the RSSI as measured during the 
period indicated by the last DL-MAP Report IE. 

The Report Response message, shown in table 36 shall be used by the SS to respond with the channel measurements 
requested in the last received Report Request. 

Table 36: REP-RSP message format 



Syntax 


Size 


Notes 


Report_Response_Message_Format () { 






Management Message Type = 37 


8 bits 




Current Tx Power 


8 bits 


Current transmit power (peak) in 0,5 dB increments 


Report Response TLV 


variable 


Compound TLV that shall contain the measurement 
Report in accordance with the Report Request 


1 







The Report Response TLV shall have the format shown in table 37. 

Table 37: Report Response TLV 



Name 


Type 


Length 


Value 


Report Response 


1 


Variable 





The Report Response shall consist of the parameters in table 38. 

Table 38: Report Response parameters 



Name 


Type 


Length 


Value 


CINR Report 


1.3 


2 


Insert if REP-REQ bit#1 = 1 

1 byte CINR mean 

1 byte CINR standard deviation 


RSSI Report 


1.4 


2 


Insert if REP-REQ bit#2 = 1 

1 byte RSSI mean 

1 byte RSSI standard deviation 
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4.3.17 Type 38: Fast Power Control (FPC) message 

Power control shall be provisioned by the use of periodic ranging. In addition, the BS may adjust the power levels of 
multiple subscribers simultaneously with the Fast Power Control (FPC) message. SSs shall apply the indicated change 
within the "SS DL management message processing time". PFC shall be sent on the broadcast CID. 

Table 39: Fast Power Control message format 



Syntax 


Size 


Notes 


Fast_Power_Control message format () { 






Management message type = 38 


8 bits 




Number of stations 


8 bits 




for (i = 0;i<Number of stations; i++) { 






Basic CID 


16 bits 




Power Adjust 


8 bits 




} 






1 







Number of stations: 

• Number of CID and Power Adjust tuples contained in this message. 
Basic CID: 

• Basic connection identifier associated with the SS. 
Power Adjust: 

• Signed integer, which expresses the change in power level (in multiples of 0,25 dB) that the SS shall apply to 
its current transmission power. 

4.3.18 Type 39: MeSH Network ConPiGuration (MSH-NCPG) message 

MeSH Network ConFiGuration (MSH-NCFG) messages provide a basic level of communication between nodes in 
different nearby networks whether from the same or different equipment vendors or wireless operators. All the nodes 
(BS and SS) in the mesh network shall transmit MSH-NCFGs as described in clause 6.5.2. 

The MSH-NCFG packets shall be used to convey information about network status and configuration such as: 

• synchronization across multiple mesh networks; 

• communication of channels in use across multiple networks; and 

• support of network entry for new or mobile nodes. 

All the nodes shall generate MSH-NCFGs in the format shown in table 40. 
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Table 40: MSH-NCFG message format 



Syntax 


Size 


Notes 


Report_Response_Message_Format () ( 






Management Message Type = 39 


8 bits 




NumNb rEntries 


5 bits 




NumBSEntries 


2 bits 


Number of mesh BS neighbours to be reported on 


Embedded_Packet_Flag 


1 bit 


1 = present, = not present 


Xmt Power 


4 bits 


In 2 clBm steps, starting from 0x0 = 8 dBm 


Xmt Antenna 


3 bits 


Antenna used for transmission of this message 


NetEntry_MAC_Address_Flag 


1 bit 


1 = present, = not present 


Network Base Channel Logical Number 


4 bits 




Reserved 


4 bits 




NetConfig Counter 


4 bits 


Incremented by 1 for every transmitted IVISH-NCFG 


TimeStamp 

Frame_Number 

Network Ctrl Slot Number in frame 

Number of hops to master sync, node 


12 bits 
4 bits 
8 bits 




NetConfig Schedule Info 
Next Xmt Mx 
Xmt Holdoff Exponent 


3 bits 
5 bits 




If (NetEntry_MAC_Address_Flag) 
NetEntry MAC Address 


48 bits 




for (i = 0; i<NumBSEntries; + + i) { 






BS Node ID 


16 bits 


Node ID of the mesh BS reported on 


Number of hops to BS 


3 bits 


Number of hops to this mesh BS 


Xmt energy/bit to BS 


5 bits 




} 






for (i = 0; i<NumNbrEntries; ++i) { 






Nbr Node ID 


16 bits 


Node ID of the neighbour node reported on 


MSH-NCFG_Nbr_Physical_IE () 


16 bits 


See table 41 


if (Logical_Link_Info_Present ) 
MSH-NCFG_Nbr_Logical_IE () 


16 bits 


Indicated in preceding MSH-Nbr Physical IE{) 
See table 42 


} 






If (Embedded_Packet_Flag) 

MSH-NCFG_embedded_data ( ) 


variable 




} 







NumNbrEntrie s : 

• Number of neighbours reported on in the message. The number of neighbours reported on may be a fraction of 
the whole set of neighbours known to this node. A node can report on subsequent subsets of neighbours in its 
subsequent MSH-NCFG transmissions. 

The following procedure is used to select the list neighbours of which only the Physical IE is reported: 

i) All neighbour entries with the "Reported Flag" set to TRUE are excluded as defined below. 

ii) The remaining neighbour entries are ordered by the Next Xmt Time and those with the Next Xmt Time 
the furthest in the future are reported in this MSH-NCFG packet. (In general, learning of nodes with Next 
Xmt Times furthest into the future is more valuable than learning of nodes with Next Xmt Times 
approaching soon, since the neighbours will have more time to use this ineligibility information before it 
is stale.) 

The "Reported Flag" for all neighbours in either of the above neighbour lists is set to TRUE upon transmission 
of this MSH-NCFG packet. It is set to FALSE as described in clause 6.5.1. 

Network Base Channel Logical Number: 

• The logical number of the base channel being used in this node's network, which is the logical number of the 
physical channel which shall be used to broadcast schedule control information. The possible physical channel 
numbers is mapped to logical channels in the Network Descriptor (see clause 4.3.18.3.1). 
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Netconfig counter: 

• Counter of MSH-NCFG packets transmitted by this node. Used by neighbours to detect missed transmissions. 
Incremented by 1 for every MSH-NCFG transmission by this node. 

Frame number: 

• A modulo 2^^ number, which shall be increased by one for every frame. 
Network Control Slot Number in frame: 

• See TS 102 177 [2] for details. 

Number of hops to master sync, node: 

This counter is used to determine superiority between nodes when synchronizing the network. Nodes can 
be assigned as master time keepers, which are synchronized externally (for example using GPS). Nodes 
shall synchronize to the node with the lowest number of hops to master sync, node, or if counts are the 
same, to the node with the lower Node ID. 

Netconfig Schedule Info 

Xmt Holdoff Exponent: 

• The Xmt Holdoff Time is the number of MSH-NCFG transmit opportunities after Next Xmt Time (there are 
MSH-CTRL-LEN -1 opportunities per network control subframe, that this node is not eligible not transmit 
MSH-NCFG packets. 

Xmt Holdoff Time = 2^^'^' «°^'^°^^ Exponent+4) ( j^ 

Next Xmt Mx: 

• Next Xmt Time is the next MSH-NCFG eligibility interval for this neighbour and computed as the range: 
2Xmt Holdoff Exponent ^ ^^^^ ^mt Mx < Next Xmt Time < 2^'"' "°''^°*'*' ^^P™™' x (Next Xmt Mx + 1). (2) 

For example, if Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be considered eligible 
for its next MSH-NCFG transmission between 49 and 64 (due to the granularity) transmission opportunities 
away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbour should be considered to be eligible to 
transmit from the time indicated by this value and every MSH-NCFG opportunity thereafter (i.e. treat Xmt 
HoldoffTime = 0). 

NetEntry MAC Address: 

• Indicates presence or sponsorship of new node. See MSH-NENT message in clause 4.3. 19 and network entry 
in clause 6.6. 

Xmt energy/bit factor: 

• Indication of energy/bit needed to reach mesh BS through this node. Xmt energy/bit is computed as: 

£■; = min [Pj^ I Rj^ j+eA mW//s (3) 



where: Nis the set of neighbours reporting this mesh BS: 

P^x is the transmission power in mW from node ; to nodey 

Ri^ j is the datarate in Mbps from node / to node j. 
E j is the Xmt energy/bit reported by neighbour y. 
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The reported Xmt energy/bit factor is computed as: 

Xmter.ergy/bitfactor = XmtenergyW^^^^^^^^^^^^^^^^_^_^^ 



(4) 



where XmtEnergyUnitExponent is a 4-bit field reported in the most recent Network Descriptor. 

4.3.18.1 Nbr Physical Information Element 

Table 41 : MSH-NCFG_Nbr_Physical_lnformation_Element 



Syntax 


Size 


Notes 


MSH-NCFG_Nbr_Physical_IE() { 






Logical Link Info Present 


1 bit 


Indicates whether IVISH-NCFG Nbr Logical IE follows 


Logical Link requested 


1 bit 


1 = Yes, = No 


Logical Link Accepted 


1 bit 


1 = Yes, = No 


Hops to Nbr 


1 bit 


= 1 hop (direct neighbour), 1 = 2 hops 


Propagation delay 


4 bits 


Estimated propagation delay in |js 


Nbr NetConfig Schedule Info 
Nbr Next Xmt Mx 
Nbr Xmt Holdoff Exponent 


5 bits 
3 bits 




} 







4.3.18.2 Nbr Logical Information Element 



Table 42: MSH-NCFG_Nbr_Logical_lnformation_Element 



Syntax 


Size 


Notes 


MSH-NCFG_Nbr_Logical_IE{) { 






Rev Link Quality 


3 bits 




Nbr Burst Profile 


4 bits 




Excess Traffic Demand 


1 bit 


1 = Yes, = No 


Nbr Xmt Power 


4 bits 


(see table 40) 


Nbr Xmt Antenna 


3 bits 


(see table 40) 


Short Preamble Flag 


1 bit 


= don't use, 1 = use requested/confirmed 


} 







Rev Link Quahty: 

• Measure of the receive Hnk reliability, indicating the reliability of MSH-NCFG size packets using the 
indicated burst profile. The estimated reliability is indicated as: 

reliability = lOOx (l - lO'^'^'^^ ^ink Quality+1)/4'J ^^ (5) 

Nbr burst profile: 

• Indicated the burst profile the indicated node should use when sending data bursts to the reporting node. 
Excess traffic demand: 

• May be used to indicate to the neighbour that the current schedule is insufficient to transfer pending traffic. 
Short Preamble flag: 

• A node may optionally set this bit to notify the neighbour to use the short preamble for transmissions in the 
data portion of the frame. Capability to transmit the short preamble is mandatory. Capability to receive it is 
optional. 
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4.3.18.3 Embedded data 

The Embedded_Data shall consist of the form shown in table 43. 

Table 43: MSH-NCFG Embedded Data 



ETSI TS 102 178 VI .2.1 (2005-01) 



Syntax 


Size 


Notes 


MSH-NCFG_Embeclded_Data() { 






Extended embedded_data 


1 bit 


Indicates whether this embedded IE is followed by 
another one. 
= No, 1 = Yes 


Reserved 


3 bits 




Embedded_Data_IE_Type 


4 bits 


0x0 = Reserved 

0x1 = Network Descriptor 

0x2 = Network Entry Open 

0x3 = Network Entry Reject 

0x4 = Network Entry Ack (Length shall be set to 0) 

0x5 = Neighbour Link Establishment Protocol 


Length 


8 bits 


Length of the MSH-NCFG_Embedded_Data_IE in 
bytes, exclusive this header 


MSH-NCFG_Embedded_data_IE 


variable 


Embedded Data IE Type dependent 


} 







4.3.18.3.1 Network Descriptor Embedded Data Information Element 

The Network Descriptor Embedded_data_IE shall contain the shown in table 44. 

Table 44: Network Descriptor Information Element 



Syntax 


Size 


Notes 


MSH-NCFG_Embedded_Data_IE { 






Frame Length Code 


4 bits 


4 Isb of Frame Duration Code. See TS 102 177 [2] 


MSH-CTRL-LEN 


4 bits 


Control subframe length 


MSH-DSCH-NUM 


4 bits 


Number of DSCH opportunities in schedule control 
subframe 


MSH-CSCH-DATA-FRACTION 


4 bits 




Scheduling Frames 


4 bits 


Defines how many frames have a schedule control 
subframe between two frames with network control 
subframes in multiples of 4 frames 

= frames; 

1 = 4 frames, etc. 


Num_Burst_Prof lies 


4 bits 




Operator ID 


16 bits 




XmtEnergyUnitsExponent 


4 bits 




Num_Channels 


4 bits 


Number of logical channels 


MinCSForwardingDelay 


7 bits 


Number of OFDM symbols delay inserted between 
receiving and forwarding control packets 


ExtendedNeighborhoodType 


1 bit 


= 2-hop neighbourhood 

1 = 3-hop neighbourhood 


If (Num_Channels) 

MSH-NCFG_NetDesc_Channel_IE () 


variable 




for (i = 0;i < BurstProf ileCount; i++) { 






FEC Code Type 


8 bits 


See table 8 


Mandatory Exit Threshold 


8 bits 


Mandatory Entry Threshold 


8 bits 


} 






} 







£75/ 



31 



ETSI TS 102 178 VI .2.1 (2005-01) 



MSH-CSCH-DATA-FRACTION: 

• Maximum percentage (value x 6,67) of minislots in the data-subframe allocated to centralized scheduling. The 
number of minislots is rounded to the nearest whole number of minislots and allocated starting from the 
beginning of the data subframe. The remainder of the data subframe, as well as any minislots not occupied by 
the current centralized schedule, may be used for distributed scheduling. 

ExtendedNeighborhoodType: 

• If value 0, then only nodes with Hops to Neighbour = are reported, if value 1, then also nodes with Hops to 
Neighbour = 1 are reported. 

MinCSForwardingDelay: 

• The minimum delay in OFDM symbols that shall be inserted between the end of reception and the start of 
transmission of a Centralized Scheduling message (i.e. MSH-CSCH and MSH-CSCF) by any node. 

Table 45: MSH-NCFG NetDesc Channel Information Element 



Syntax 


Size 


Notes 


MSH-NCFG_NetDesc_Channel_IE() { 






for (i = 0;i< Channels; ++i) { 




PHY dependent. Index T corresponds to logical 
channel 


Physical channel centre frequency 


24 bits 


Positive integer in kHz 


Physical channel width 


8 bits 


Positive integer in 100 kHz 


} 






Channel Re-use 


3 bits 


IVIinimum number of hops of separation between links, 
before a channel can be re-used by the centralized 
scheduling algorithm. Range is 1 hop to 7 hops, for 
no re-use 


Reserved 


5 bits 




} 







4.3.18.3.2 



Network Entry Open Embedded Data Information Element 



The Network Entry Open, which is used to respond to MSH-NENT request messages, shall contain the form as shown 
in table 46. 

Table 46: Network Entry Open Information Element 



Syntax 


Size 


Notes 


MSH-NCFG_Embedded_Data_IE() { 






Minislot Start 


8 bits 


Schedule start for upper layer network entry 


Minislot Range 


8 bits 


Schedule range for upper layer network entry 


Frame number 


12 bits 


Frame number this schedule becomes valid 


Channel 


4 bits 


Logical channel for new node to Xmt in above Minislot 
Range 


Schedule validity 


12 bits 


Validity of Schedule in frames 


Channel 


4 bits 


Logical Rev channel for new node 


Estimated Propagation Delay 


4 bits 


In |js 


Reserved 


4 bits 




} 
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4.3.18.3.3 



Network Entry Reject Embedded Data Information Element 



The Network Entry Reject, which is used to reject MSH-NENT request messages, shall contain the form as shown in 
table 47. 

Table 47: Network Entry Reject Information Element 



Syntax 


Size 


Notes 


MSH-NCFG_Embedded_Data_IE{) { 






Rejection Code 


8 bits 


0x0: Operator Authentication Value Invalid 
0x1 : Excess Propagation delay 
0x2: Select new sponsor 


Rejection Reason 


1 60 bits 


ASCII string 


} 







4.3.18.3.4 



Neighbour Link Establishment Embedded Data Information Element 



The Neighbour Link Establishment, which is used to establish links between nodes as described in clause 6.2, shall 
contain the form as shown in table 48. 

Table 48: Link Establishment Information Element 



Syntax 


Size 


Notes 


MSH-NCFG_Embedded_Data_IE() { 






Action Code 


2 bits 


0x0 = Challenge 

0x1 = Challenge Response 

0x2 = Accept 

0x3 = Reject 


Reserved 


6 bits 




if (Action Code == 0x0 or 0x1) 
Nbr Authentication Value 


32 bits 




if (Action Code == 0x1 or 0x2) 
Link ID 


8 bits 


Transmitting node's Link ID for this link 


} 







Nbr Authentication Value: 

Nbr Authentication Value = HMACJAuthorization Key I Frame Number I Node ID self I Node ID other} (6) 
where the Authorization Key is a secret key (obtained from Operator). 

4.3.19 Type 40: MeSH-Network ENTry (MSH-NENT) message 

MeSH Network ENTry (MSH-NENT) messages provide the means for a new node to gain synchronization and initial 
network entry into a mesh network. When a MSH-NENT message, shown in table 49, is sent, the mesh Subheader is set 
to 0x0000 until the node has been assigned a node ID. In the Mesh CID, The Network ID is set the sponsor's network 
code or to 0x0000 if not known and the Link ID is set to OxFF (Broadcast). 
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Table 49: MSH-NENT message format 



Syntax 


Size 


Notes 


MSH-NENT_Message„Format { 






MAC Management Message Type = 40 


8 bits 




MSH-NENT„Type 


3 bits 


0x0 = Reserved 
0x1 = NetEntryAcl< 
0x2 = NetEntryRequest 
0x3 = NetEntryClose 


if (MSH-NENT_Type == 0x1) 

MSH-NENT_Type being Ack-ed 

else 

Xmt counter for this MSH-NENT_Type 


3 bits 
3 bits 




Reserved 


2 bits 




Sponsor Node ID 


16 bits 


ID of the node sought to assist the requesting node in 
entering the network 


Xmt Power 


4 bits 


See table 40 


Xmt Antenna 


3 bits 


See table 40 


Reserved 


1 bit 




if (MSH-NENT_Type == 0x2) 






MAC Address 


48 bits 


MAC Address of the new node sending the request. 


OpConf Info 


64 bits 


Operator Configuration Information (obtained from 
Operator) 


Operator Authentication Value 


32 bits 




Node Serial Number 


32 bits 




} 






} 







Operator Authentication Value: 

Operator Authentication Value = HMACJMAC Address I Node Serial Number I Authorization Key} (7) 
where the Authorization Key is a secret key (obtained from Operator) 

4.3.20 Type 41 : MeSH-Distributed SCHeduling (MSH-DSCH) message 

MeSH Distributed SCHeduling (MSH-DSCH) messages shall be transmitted in mesh mode when using distributed 
scheduling. In coordinated distributed scheduling, all the nodes shall transmit a MSH-DSCH, shown in table 50 at a 
regular interval to inform all the neighbours of the schedule of the transmitting station. This transmission time is 
determined by the same algorithm used for MSH-NCFG messages. In both coordinated and uncoordinated scheduling, 
MSH-DSCH messages shall be used to convey resource requests and grants to the neighbours. Further the MSH-DSCH 
messages shall be used to convey information about free resources that the neighbours can issue grants in. This message 
shall not be fragmented. 
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Table 50: MSH-DSCH message format 



Syntax 


Size 


Notes 


MSH-DSCH_Message_Format { 






MAC Management Message Type = 41 


8 bits 




Coordination Flag 


1 bit 


= Coordinated 

1 = Uncoordinated 


Grant/Request Flag 


1 bit 


= Request message 

1 = Grant message (also used as Grant confirmation) 


MSH-DSCH Sequence Counter 


6 bits 




Num_Re quests 


4 bits 


Number of Request lEs in the message 


Num_Avai labilities 


4 bits 


Number of Availability lEs in the message. The 
Availability lEs are used to indicate free minislot 
ranges that neighbours could issue Grants in 


Num_Grants 


6 bits 


Number of Grant IBs in this message 


Reserved 


2 bits 




if (Coordination Flag == 0x0) 
MSH-DSCH_Scheduling_IE () 


variable 




for (i = 0;i< Num_Requests; ++i) 
MSH-DSCH_Request_IE () 


16 bits 




for {i = 0;i< Num_Availabilities; ++i) 
MSH-DSCH_Availability_IE () 


32 bits 




for (i = 0;i< Num_Grants; ++i) 
MSH-DSCH_Grant_IE ( ) 


40 bits 




} 







Co-ordination Flag: 



• Coordinated MSH-DSCH transmissions take place in the control subframe. Uncoordinated MSH-DSCH 
transmissions take place in the data subframe. Both the cases require a threeway handshake (Request, Grant 
and Grant confirmation) to establish a valid schedule. Uncoordinated scheduling may only take place in 
minislots which cause no interference with the coordinated schedule. 

Grant/Request Flag: 

• The Request Type indicates that a new Request is made of one or more other nodes. The No. Requests shall be 
non-zero in this case. The message may also contain Availabilities and Grants. 

The Grant Type indicates that one or more Grants are given or confirmed. The Num_Grants shall be non-zero 
in this case. The message may also contain Availabilities and Requests. Requests in this type of message 
indicate pending demand to the indicated node(s), but do not solicit a Grant from this node. 
This flag is always set to for coordinated distributed scheduling. 

MSH-DSCH Sequence Counter: 

• Sequentially increased counter for solicit messages in uncoordinated scheduling (used as multiple solicits 
might be outstanding). In coordinated scheduling, it allows nodes to detect missed scheduling messages. 
Independent counters are used for the coordinated and uncoordinated messages. 

4.3.20.1 MSH-DSCH Scheduling Information Element 

The Coordinated distributed scheduling information carried in the MSH-DSCH message, shown in table 51, shall be 
used to distribute information needed to determine transmission timing of the MSH-DSCH messages with coordinated 
distributed scheduling. Each node shall report the two related parameters both of its own and all its neighbours. 
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Table 51 : MSH-DSCH Scheduling Information Element 



Syntax 


Size 


Notes 


MSH-DSCH_Scheduling_IE { 






DSCH Schedule Info 
Next Xmt Mx 
Xmt Holdoff Exponent 


3 bits 
5 bits 




Num_SchedEntries 


8 bits 


Number of Neiglibour IVISH-DSCH Scheduling Entries 
in the message. 


for (i = 0; i< Num_SchedEntries; ++i) { 






Nbr Node ID 


16 bits 


The Node ID of the neighbour being reported on. 


Nbr DSCH Schedule Info 
Nbr Next Xmt Mx 
Nbr Xmt Holdoff Exponent 


3 bits 
5 bits 


Advertise as reported by neighbour. 


} 







DSCH Schedule Info. 
Xmt Holdoff Exponent: 

• The Xmt Holdoff Time is the number of MSH-DSCH transmit opportunities after Next Xmt Time (there are 
MSH-CTRL-LEN -1 opportunities per network control subframe, that this node is not eligible not transmit 
MSH-DSCH packets. 

Xmt Holdoff Time = 2^^"^' "°''^°f*' Exponent+4) (g^ 

Next Xmt Mx: 

• Next Xmt Time is the next MSH-DSCH eligibility interval for this neighbour and computed as the range 

jXmt Holdoff Exponent ^ ^^^^ ^mt Mx < Next Xmt Time < 2^™' ""''^"^^ Exponent ^ ^ j^^^^ ^mt Mx + 1) (9) 

EXAMPLE: If Next Xmt Mx = 3 and Xmt Holdoff Exponent = 4, then the node shall be considered eligible for 
its next MSH-DSCH transmission between 49 and 64 (due to the granularity) transmission 
opportunities away and ineligible before that time. 

If the Next Xmt Mx field is set to OxlF (all ones), then the neighbour should be considered to be 
eligible to transmit from the time indicated by this value and every MSH-DSCH opportunity 
thereafter (i.e. treat Xmt Holdoff Time = 0). 

4.3.20.2 MSH-DSCH Scheduling Information Element 

The Requests carried in the MSH-DSCH message shall convey resource requests on per link basis, as shown in table 52. 

Table 52: MSH-DSCH Request Information Element 



Syntax 


Size 


Notes 


MSH-DSCH_Request_IE() { 






Link ID 


8 bits 


The ID assigned by the transmitting node to the link to 
this neighbour that this request involves. 


Demand Level 


8 bits 


Demand in minislots (assuming the current burst 
profile). 


Persistence 


3 bits 


Persistency field for demands. Number of frames over 

which the demand exists. 

= cancel reservation, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames , 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced. 


Reserved 


1 bits 




1 
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4.3.20.3 MSH-DSCH Availability Information Element 

The Availabilities carried in the MSH-DSCH message shall be used to indicate free minislot ranges that neighbours 
could issue Grants in. Each Availability shall be indicated using the IE shown in table 53. 

Table 53: MSH-DSCH Availability Information Element 



Syntax 


Size 


Notes 


MSH-DSCH_Availability_IE() { 






Start Frame Number 


8 bits 


Indicates lowest 8 bits of frame number in which the availability 
starts. 


Minislot start 


8 bits 


The start position of the availability within the frame. 


Minislot Range 


7 bits 


The number of consecutive available minislots. 


Direction 


2 bits 


= Minislot range is unavailable. 

1 = Available for transmission in this minislot range. 

2 = Available for reception in this minislot range. 

3 = Available for either transmission or reception. 


Persistence 


3 bits 


Persistency field for Availabilities. Number of frames over which 

the Availability is valid. 

= cancel availability, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced. 


Channel 


4 bits 


Logical channel number on which the availability exists. 


1 







4.3.20.4 



MSH-DSCH Grant Information Element 



The Grants carried in the MSH-DSCH message shall convey information, as shown in table 54, about a granted minislot 
range selected from the range reported as available. Grants shall be used both to grant and confirm a grant. 

Table 54: MSH-DSCH Grant Information Element 



Syntax 


Size 


Notes 


MSH-DSCH_Grant_IE() { 






Link ID 




The ID assigned by the transmitting node to the neighbour that 
this Grant involves. 


Start Frame Number 


8 bits 


Indicates lowest 8 bits of frame number in which the Grant starts. 


Minislot start 


8 bits 


The start position of the Grant within the frame. 


Minislot Range 


7 bits 


The number of consecutive minislots granted. 


Direction 


2 bits 


= From requester to grantor. 

1 = To requester from grantor. 


Persistence 


3 bits 


Persistency field for Grants. Number of frames over which the 

Availability is valid. 

= cancel reservation, 1 = single frame, 

2 = 2 frames, 3 = 4 frames, 

4 = 8 frames, 5 = 32 frames, 

6= 128 frames, 

7 = Good until cancelled or reduced. 


Channel 


4 bits 


Logical channel number on which the availability exists. 


1 







4.3.21 Type 42: MeSH-Centralized SCHeduling (MSH-CSCH) message 

A MeSH Centralized SCHeduling (MSH-CSCH) message shall be created by a mesh BS when using centralized 
scheduling. The BS shall broadcast the MSH-CSCH message, as shown in table 55, to all its neighbours, and all the 
nodes with hop count lower than HOPRANGE_THRESHOLD shall forward the MSH-CSCH message to their 
neighbours that have a higher hop count. In all these cases, the Grant/Request Flag = 0. HOPRANGE_THRESHOLD is 
a configuration value that need only be known to the mesh BS, as it can be derived by the other nodes from the 
MSH-CSCF message. 
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Nodes can use MSH-CSCH messages to request bandwidth from the mesh BS setting the Grant/Request Flag = 1. Each 
node reports the individual traffic demand requests of each "child" node in its subtree from the BS. The nodes in the 
subtree are those in the current scheduling tree to and from them mesh BS, known to all nodes in the network, and 
ordered by node ID. 

Table 55: MSH-CSCH message format 



Syntax 


Size 


Notes 


MSH-CSCH_Message_Format { 






MAC Management Message Type = 42 


8 bits 




MSH-CSCF Sequence Number 


3 bits 


Indicates the configuration, which shall be used to 
interpret this packet. 


Grant /Request Flag 


1 bit 


= Grant message (transmitted up the tree). 

1 = Request message (transmitted down the tree). 


Frame Schedule Flag 


1 bit 


If this flag is set, the allocation of flows shall occur 
over two frames, rather than one. 


Configuration Flag 


1 bit 




Reserved 


2 bits 




Num_FlowEntries 


8 bits 




for (i = 0;i< Num_FlowEntries; ++i) { 






UL_Flow 


4 bits 




If (Grant/Request Flag == 0) 






DL_Flow 


4 bits 




} 






FlowScale Exponent 


4 bits 




Padding Nibble 


4 bits 


Pad till byte boundary. 


If (Grant/Request Flag == 1) { 






Num_LinkUpdates 


4 bits 




for (i = 0;i< Num_LinkUpdates; ++i) { 






Node Index self 


8 bits 


Index self in IVISH-CSCF list. 


Node Index parent 


8 bits 


Index parent in IVISH-CSCF list. 


UL Burst Profile 


4 bits 


Burst Profile for transmitting up the tree. 


DL Burst Profile 


4 bits 


Burst Profile for transmitting down the tree. 


} 






} else { 




Sponsor Node Request. 


Sponsor Node 


8 bits 


index in MSH-CSCF list. 


DL Burst Profile 


4 bits 




UL Burst Profile 


4 bits 




} 






} 







Sponsor Node Request: 

• Three parameters (Sponsor Node, and Burst Profiles) shall be set to 0, except by nodes which wish to reserve 
an allocation for the "upper MAC initialization" as specified in clause 6.6.4. A node may only set these values 
if all its children report these values as 0. The Mesh BS shall in response provide a grant to Node Index 0x00, 
which shall be reserved for this purpose. 

Configuration Flag: 

• Indicates which centralized scheduling control message type (CSCH or CSCF) will be transmitted next by the 
Mesh BS. This bit may be set to aid the nodes in computing the validity of the schedule indicated in the current 

message (see clause 6.8.2). 



FlowScale Exponent: 



Determines scale of the granted bandwidth. Its value typically depends on the number of nodes in the network, 

the achievable PHY bitrate, the traffic demand and the provided service. 

For the DL, this gives the absolute values of flow granted, so the total minislot range allowed for centralized 

scheduling need not be used if not needed, with the remainder set aside for distributed scheduling. 

For the UL, the lowest exponent possible is used at each hop, with quantization of forwarded requests rounded 

up (e.g. avoids reducing any requests to zero). 
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NumFlowEntries: 



Number of 8-bit assignment fields followed, ordered according to appearance in MSH-CSCF. This number 
shall match the number of entries in the most recent MSH-CSCF message. 



UL_Flow. 
DL Flow: 



Base of the granted/requested bandwidth as bits/s for DL respectively UL traffic of the node in the BS's 
scheduling tree. The flow only indicates traffic that initiates or terminates in the node itself (i.e. forwarded 
traffic is not included), except for traffic forwarded from/to nodes not part of the MSH-CSCF tree. The actual 
granted/requested bandwidth shall be calculated as: 



BWuL =UL_Flowx(2P*°*^'=^''=E''P°"'="'+'4) ^-^^/^ 
BWdl =DL_Flowx(2P'°*^'=^''=E''P™™'+i4) ^-^^/^ 



(10) 



The assignments in the list are ordered according to the order in the MSH-CSCF message. 

Num_LinkUpdates : 

• Link updates are inserted by the mesh BS if the number of link tree changes does not warrant a MSH-CSCF 
broadcast. The mesh BS shall repeat the link update in every MSH-CSCH either until the update becomes 
invalid, or until the change is reflected in a MSH-CSCF message. 

4.3.22 Type 43: MeSH-Centralized Scheduling ConFiguration (MSH-CSCF) 
message 

A MeSH Centralized Scheduling ConFiguration (MSH-CSCF) message shall be broadcast in mesh mode when using 
centralized scheduling. The mesh BS shall broadcast the MSH-CSCF message, as shown in table 56, to all its 
neighbours, and all nodes shall forward (rebroadcast) the message according to its index number specified in the 

message. 

Table 56: MSH-CSCF message format 



Syntax 


Size 


Notes 


MSH-CSCF_Message_Format { 






MAC Management Message Type = 43 


8 bits 




MSH-CSCF Sequence Number 


4 bits 


The BS shall increment this number by one for every 
MSH-CSCF message it transmits. 


Num_Channels 


4 bits 


Number of channels available for centralized 
scheduling. 


for (i = 0;i< Num_Channels ; ++i) { 
Logical Channel Number 


4 bits 


The logical index of the Physical channel, as reported 
in MSH-NCFG Network Descriptor. 


Padding nibble 


0/4 bits 


Pad till byte boundary. 


Num_Nodes 


8 bits 




for (i = 0;i< Num_Nodes; ++i) { 






Node ID 


16 bits 


Unique node identifier assigned to node. 


Num_Children 


8 bits 




for (j = 0;j< Num_Children; ++j) { 






Child Index 


8 bits 


Index child in Node list. 


UL Burst Profile 


4 bits 


Burst Profile for transmitting up the tree from this child. 


DL Burst Profile 


4 bits 


Burst Profile for transmitting down the tree to this child. 


} 






} 






} 
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4.3.23 Type 44/45: AAS-FeedBaCK REQuest/ReSPonse (AAS-FBCK 
REQ/RSP) message 

AAS Feedback messages as shown in table 57 and table 58 are used to obtain channel state information as described in 
clause 7.4. 

Table 57: AAS-FeedBaCK REQuest (AAS-FBCK-REQ) message format 



Syntax 


Size 


Notes 


AAS_Feedback_Request_Message_Format () { 






Management Message Type = 44 


8 bits 




Frame Number 


24 bits 




Number of Frames 


7 bits 




Measurement Data Type 


1 bits 


= measure on DL preamble only 

1 = measure on DL data (for this SS) only 


Feedback Request Counter 


6 bits 




Frequency Measurement 
Subcarrier Resolution 


2 bits 


ObOO= 4 
Ob01 = 8 
0b10 = 16 
Ob1 1 = 32 


} 







Frame Number: 

• The Frame Number in which the measurement shall be started. 
Number of Frames: 

• The number of frames over which the measurement shall be averaged. 
Frequency Measurement Subcarrier Resolution: 

• Indicates the frequency measurement points to report on. Measurement points shall be on the frequencies 
corresponding to the negative subcarrier offset indices -Nuj,gjj/2 plus n times the indicated subcarrier resolution 
and corresponding to the positive subcarrier offset indices Nuj,gy2 minus n times the indicated subcarrier 
resolution where n a positive integer. See TS 102 177 [2], clause 4.2. 

Feedback Request Counter: 

• Increased by one every time an AAS-FBCK-REQ is sent to the SS. Individual counters shall be maintained for 
each SS. 

Table 58: AAS-FeedBaCK-ReSPonse (AAS-FBCK-RSP) message format 



Syntax 


Size 


Notes 


AAS_Feedback_Response_Message_Format () { 






Management Message Type = 45 


8 bits 




Reserved 


2 bits 


Set to ObOO 


Feedback Request Counter 


6 bits 




for (i = 0; i<Number of Frequencies; i++) { 




According to Frequency Measurement 
Subcarrier Resolution 


Re (Frequency [i] ) 


8 bits 




Im (Frequency [i] ) 


8 bits 




} 






} 







Feedback Request Counter: 

• Counter from the AAS-FBCK-REQ messages to which this is the response. 
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Frequency: 

• The Real (Re) and Imaginary (Im) part of the measured amphtude on the frequency measurement point (low to 
high frequency) in signed integer fixed point format ([±][4 bits]. [4 bits]. 

4.3.24 Type 46 to 255: DUMMY message 

A SS shall be capable of decoding the DUMMY message shown in table 59. A BS shall not transmit this message 
unless in test mode. A SS shall not transmit this message. 

Table 59: DUMMY message format 



Syntax 


Size 


Notes 


DUMMY_Message_Format { 






Management Message Type = 46... 255 


8 bits 




Length 


8 bits 




Unspecified data 


Length x 8 bits 




} 







Length: 



The Length in bytes of the following "Unspecified data". 



Automatic Repeat reQuest (ARQ) 



The ARQ mechanism is an optional part of the MAC layer and can be enabled on a per-connection basis. The 
per-connection ARQ and associated parameters shall be specified and negotiated during connection creation or change. 
A connection cannot have a mixture of ARQ and non-ARQ traffic. Similar to other properties of the MAC protocol the 
scope of a specific instance of ARQ is limited to one unidirectional connection. 

For ARQ-enabled connections, enabling of fragmentation is optional. When fragmentation is enabled, the transmitter 
may partition each SDU into fragments for separate transmission based on the value of the ARQ_BLOCK_SIZE 
parameter. 

Connections are set and defined dynamically through the DS A/DSC class of messages. CRC-32 shall be used for error 
detection of PDUs for all ARQ-enabled connections. All ARQ parameters (see clause 5.2) shall be set and all ARQ 
variables (see clause 5.3) shall be reset (set to 0) on connection setup. 

ARQ feedback information can be sent as a standalone MAC management message (see table 30) on the appropriate 
basic management connection, or can be piggybacked on an existing connection using the ARQ Feedback Payload 
(see table 60). ARQ Feedback message shall not be fragmented. 

5.1 Packing for ARQ-enabled connections 

The use of packing subheaders for ARQ-enabled connections is similar to that for non-ARQ connections, except that 
ARQ-enabled connections use Packing or Fragmentation Subheaders of Extended Type, so bit#3 in the general MAC 
header's Type field shall be set (see table 1). MAC PDUs transmitted at ARQ-enabled connections must have either 
Fragmentation Subheader or Packing Subheaders to provide each payload with block sequence numbers information. If 
packing is turned on for a connection, the MAC may pack multiple MAC SDUs or fragments thereof into a single 
MAC PDU. The transmitting side has full discretion whether or not to pack a group of MAC SDUs and/or fragments in 
a single MAC PDU. The packing of variable-length MAC SDUs for the ARQ-enabled connections is similar to that of 
non-ARQ connections, when fragmentation is enabled. The BSN of the Packing Subheader shall be used by the ARQ 
protocol to identify and retransmit lost fragments. 

5.1 .1 Interaction of packing with fragmentation 

For ARQ-enabled connections, when the general MAC header's Type (see table 1) indicates packing is used (i.e. when 
bit#5 is set) , fragmentation information for each individual MAC SDU or MAC SDU fragment is contained in the 
associated Packing Subheader. 
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When the Type field indicates that packing is not used, fragmentation information for the MAC PDU's single payload 
(MAC SDU or MAC SDU fragment) is contained in the Fragmentation Subheader. Each of the packed MAC SDU or 
MAC SDU fragments or ARQ feedback payload shall have its own packing subheader and some of them may be 
transmissions while others are re-transmissions. 

5.1 .2 Packing ARQ Feedback Information Elements 

An ARQ Feedback Payload (see table 60) consists of one or more ARQ Feedback Information Elements (see table 61). 
The ARQ Feedback Payload may be sent on an ARQ or non-ARQ connection. However, policies based on 
implementation and/or QoS constraints may restrict the use of certain connections for transporting the ARQ Feedback 
Payload. The ARQ Feedback Payload is treated like any other payload (SDU or fragments) from the packing 
perspective, except that only one ARQ Feedback Payload shall be present within a single MAC PDU. 

Table 60: ARQ Feedback Payload 



Syntax 


Size 


Notes 


ARQ Feedback Payload { 






do 






ARQ_Feedback_IE (last) 


variable 


Insert as many as desired, until last == TRUE 


until (last) 






1 







The presence of an ACK Feedback Payload in a MAC PDU is indicated by the value of bit #4 of the Type field in the 
generic MAC header. When present, the first packed payload shall be the ARQ Feedback Payload. The Packing 
Subheader preceding the ARQ Feedback Payload indicates the total length of the payload including the Packing 
Subheader and all ARQ Feedback Information Elements within the payload. The FSN/BSN field of the Packing 
Subheader shall be ignored for the ARQ Feedback Payload and the EC bits shall be set to ObOO. 

Table 61 : ARQ Feedback Information Element 



Syntax 


Size 


Notes 


ARQ_feedback_IE (last) { 


variable 




CID 


16 bits 


The ID of the connection being referenced. 


Last 


1 bit 


= More ARQ feedback IE in the list. 

1 = Last ARQ feedback IE in the list. 


ACK Type 


2 bit 


0x0 = Selective ACK entry, 

0x1 = Cumulative ACK entry, 

0x2 = Cumulative with Selective ACK entry, 

0x3 = Cumulative ACK with Block Sequence Ack 

entry. 


BSN 


1 1 bits 




Num_ACK_Maps 


2 bits 


If ACK Type == 01 , the field is reserved and set to 00. 
Otherwise the field indicates the number of ACK maps: 
0x0 = 1 , 
0x1 = 2, 
0x2 = 3, 
0x3 = 4. 


if (ACK Type! =01) { 






for (1=0; i< NUM_ACK_Maps; ++i) { 






if (ACK Type! = 03) { 






Selective ACK Map 


16 bits 




} 






else { 






Sequence Format 


1 bit 


Number of block sequences associated with descriptor 
0: 2 block sequences 
1 : 3 block sequences 


if (Sequence Format = 0) { 






Sequence ACK Map 


2 bits 




Sequence 1 Length 


6 bits 




Sequence 2 Length 


6 bits 




Reserved 


1 bit 




} 







£75/ 



42 



ETSI TS 102 178 VI .2.1 (2005-01) 



Syntax 


Size 


Notes 


else { 






Sequence ACK Map 


3 bits 




Sequence 1 Length 


4 bits 




Sequence 2 Length 


4 bits 




Sequence 3 Length 


4 bits 




} 






} 






} 






} 






} 







BSN: 



If (ACK Type == 0x0): BSN value corresponds to the most significant bit of the first 16-bit ARQ ACK map. 

If (ACK Type == 0x1): BSN value indicates that its corresponding block and all blocks with lesser values 
within the transmission window have been successfully received. 

If (ACK Type == 0x2): Combines the functionality of types 0x0 and 0x1. 

If (ACK Type == 0x3): Combines the functionality of type 0x1 with the ability to acknowledge reception of 
ARQ blocks in terms of block sequences. A block sequence is defined as a set of ARQ blocks with 
consecutive BSN values. With this option, members of block sequences are identified and associated with the 
same reception status indication. 



Selective ACK Map: 



Each bit set to one indicates the corresponding ARQ block has been received without errors. The bit 
corresponding to the BSN value in the IE, is the most significant bit of the first map entry. The bits for 
succeeding block numbers are assigned left-to-right (MSB to LSB) within the map entry. If the ACK Type 
is 0x2, then the most significant bit of the first map entry shall be set to one and the IE shall be interpreted as a 
cumulative ACK for the BSN value in the IE. The rest of the bitmap shall be interpreted similar to ACK 
Type 0x0. 



Sequence ACK Map: 



Each bit set to one indicates the corresponding block sequence has been received without error. The MSB of 
the field corresponds to the first sequence length field in the descriptor. The bits for succeeding length fields 
are assigned left-to-right within the map entry. Since the block sequence described by the first descriptor of the 
first map entry of the IE corresponds to the sequence of blocks immediately after the Cumulative ACK, the 
ACK map bit for this sequence shall be zero indicating this sequence has not yet been received. 



Sequence Length: 



This value indicates the number of blocks that are members of the associated sequence. The BSN of the first 
block of the block sequence described by the first descriptor of the first IE map entry is the value of the 
Cumulative ACK plus one. The BSN of the first block of each block sequence is determined by adding the 
BSN of the first block of the previous block sequence to the length of that sequence. Within a map entry. 
Sequence Map/Length ordering follows the rule specified in the definition of Sequence ACK Map. Across 
map entries, ordering moves from the first map entry (i=0) to the last map entry (i=Number of ACK Maps). 



5.2 ARQ parameters 



ARQ_BLOCK_SIZE: 

• ARQ_BLOCK_SIZE is the basic retransmission unit and it should be negotiated during connection setup. The 
concept of blocks is described in clause 5.4. 

ARQ_BSN_MODULUS: 

• ARQ_BSN_MODULUS is equal to the number of unique BSN values, i.e. 2 048. 
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ARQ_WINDOW_SIZE: 



• ARQ_WINDOW_SIZE is the maximum number of the unacknowledged ARQ blocks at any given time, 
which shall be less than or equal to half of ARQ_BSN_MODULUS. An ARQ block is unacknowledged if it 
has been transmitted but no acknowledgement has been received. 

ARQ_BLOCK_LIFETIME: 

• ARQ_BLOCK_LIFETIME is the maximum time interval beyond which a transmitter shall discard 
unacknowledged ARQ blocks. 

ARQ_RETRY_TIMEOUT: 

• ARQ_RETRY_TIMEOUT is the minimum time interval a transmitter shall wait before retransmitting an 
unacknowledged ARQ block. 

ARQ_SYNC_LOSS_TIMEOUT: 

• ARQ_SYNC_LOSS_TIMEOUT is the length of a time interval from last transmitted/received SDU, in which 
at least one MAC PDU was transmitted/received with no change in the position of ARQ Tx/Rx window, after 
this time interval passed, ARQ synchronization shall be considered lost. 

ARQ_RX_PURGE_TIMEOUT: 

• ARQ_RX_PURGE_TIMEOUT is the time interval the receiver shall wait after successful reception of a block 
that does not result in advancement of ARQ_RX_WINDOW_START, before advancing 
ARQ_RX_WINDOW_START. 

5.3 ARQ variables 

ARQ_TX_WINDOW_START: 

• All ESN up to (ARQ_TX_WINDOW_START - 1) have been acknowledged. 
ARQ_TX_NEXT_BSN: 

• BSN of the next block to send. This value shall be between ARQ_TX_WINDOW_START and 
(ARQ_TX_WINDOW_START + ARQ_WINDOW_SIZE). 

ARQ_RX_WINDOW_START: 

• All BSN up to (ARQ_RX_WINDOW_START - 1) have been correctly received. 
ARQ_RX_HIGHEST_BSN: 



• 



BSN of the highest block received, plus one. This value shall be between ARQ_RX_WINDOW_START and 
(ARQ_RX_WINDOW_START + ARQ_WINDOW_SIZE). 



5.4 ARQ operation 
5.4.1 ARQ block usage 

The clause describes the use of blocks for ARQ. A MAC SDU is logically divided into blocks of given 
ARQ_BLOCK_SIZE. The last block of a MAC SDU may be smaller than ARQ_BLOCK_SIZE. Once defined, the 
block never changes. 

This value of the ARQ_BLOCK_SIZE TLV specifies the ARQ block size. This parameter is negotiated upon 
connection setup. The DSA-REQ shall contain the suggested value of this parameter. The DSA-RSP message shall 
contain the confirmation value or an alternate value for this parameter. 
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A set of blocks selected for transmission or retransmission is encapsulated into a PDU. A PDU may contain blocks that 
are transmitted for the first time as well as retransmitted blocks. If fragmentation is enabled for this connection, the 
fragmentation shall occur only on ARQ block boundaries. If a PDU is not packed, all the blocks in that PDU must have 
contiguous block numbers. When a PDU is packed, any sequence of blocks between MAC subheaders and the sequence 
of blocks after the last packing subheader must have contiguous block numbers. 

If ARQ is enabled at the connection. Fragmentation and Packing subheaders contain a BSN, which is the sequence 
number of the first ARQ block in the sequence of blocks following this subheader. It is a matter of transmitter's policy 
whether a set of blocks once transmitted as a single PDU should be retransmitted also as a single PDU or not. Figure 1 
illustrates the use of blocks for ARQ transmissions and retransmissions; two options for retransmission presented: with 
and without rearrangements of blocks. 
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Retransmission of PDU without rearrangement 
Figure 1 : Block usage examples for ARQ transmissions and retransmissions 

5.4.2 Comparison of BSNs 

As numbers assigned to blocks occasionally wrap around zero, BSNs cannot be compared by directly comparing their 
values. Instead, both BSNs need to be normalized before a comparison can be made. Normalization of a BSN on the 
transmit side is accomplished using the expression: 



bsn' = (bsn - BSN_base) mod ARQ_BSN_MODULUS 

The base values for the receiver and transmitter state machines are ARQ_TX_WINDOW_START and 
ARQ_RX_WINDOW_START, respectively. 



(11) 
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5.4.3 Transmitter state machine 

An ARQ block may be in one of the following three states: Not-sent, Outstanding, Discarded, Waiting-for-retransmit. 
Any ARQ block begins as Not-sent, and transfers to other states as shown in figure 2. 

For a given connection, the transmitter shall first handle (transmit or discard) blocks in Waiting-far- retransmit state and 
only then blocks in Not-sent state. Blocks in Outstanding, Discarded, or Done state shall not be transmitted. When 
blocks are retransmitted, the block with the lowest FSN shall be retransmitted first. 

When a block in not-sent state is included in a MAC PDU, it is assigned the current value of ARQ_TX_NEXT_BSN, 
which is then incremented. 




ARQ_FRAGMENT_LIFETIME 



Figure 2: Transmitter ARQ state machine 

When any acknowledgement is received, the transmitter shall check the validity of the BSN(s). A BSN is valid if: 

ARQ_TX_WINDOW_START <BSN < ARQ_TX_NEXT_BSN-1 (12) 

If the BSN is invalid, the transmitter shall ignore the acknowledgement. All timers associated with acknowledged 
blocks shall be cancelled. 

When a cumulative acknowledgement with a valid BSN is received, the transmitter shall consider all blocks in the 
interval ARQ_TX_WINDOW_START to BSN (inclusive) as acknowledged and set ARQ_TX_WINDOW_START to 
BSN+1. 

When a selective acknowledgement is received, the transmitter shall consider as acknowledged all blocks so indicated 
by the entries in the bitmap for valid BSN values. . As the bitmap entries are processed in increasing BSN order, 
ARQ_TX_WINDOW_START shall be incremented each time the BSN of an acknowledged block equals 
ARQ_TX_WINDOW_START. 

When ARQ_TX_WINDOW_START has been advanced by either of the above methods and acknowledgement of 
reception has already been received for the fragment with the BSN value now assigned to 

ARQ_TX_WINDOW_START, the value of ARQ_TX_WINDOW_START shall be incremented until a BSN value is 
reached for which no acknowledgement has been received. 

A bitmap entry not indicating A bitmap entry not indicating acknowledgement shall be considered a NACK for the 
corresponding blocks. 

When a cumulative with selective acknowledgement with a valid BSN is received, the transmitter performs the actions 
described above for cumulative acknowledgement, followed by those for a selective acknowledgement. 

All timers associated with acknowledged blocks shall be cancelled. 

A Discard message shall be sent following violation of ARQ_BLOCK_LIFETIME. The message may be sent 
immediately or may be delayed up to ARQ_RX_PURGE_TIMEOUT + ARQ_RETRY_TIMEOUT. Following the first 
transmission, subsequent discard orders shall be sent to the receiver at intervals of ARQ_RETRY_TIMEOUT until an 
acknowledgment to the discarded BSN has been received. Discard orders for adjacent BSN values may be accumulated 
in a single Discard message. 
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5.4.4 Receiver state machine 



When a PDU is received, its integrity shall be determined based on the CRC-32 checksum. If a PDU passes the 
checksum, it is unpacked and de -fragmented, if necessary. The receiver maintains a sliding-window defined by 
ARQ_RX_WINDOW_START state variable and the ARQ_WINDOW_SIZE parameter. When an ARQ block with a 
number that falls in the range defined by the sliding window is received, the receiver shall accept it. ARQ blocks with 
numbers outside the sliding window shall be rejected. The receiver should discard duplicate ARQ blocks (i.e. ARQ 
blocks that where already received correctly) within the window. 

The sliding window is maintained such that the ARQ_RX_WINDOW_START variable always points to the lowest 
numbered ARQ block that has not been received or has been received with errors. When an ARQ block with a number 
corresponding to the ARQ_RX_WINDOW_START is received, the window is advanced (i.e. ARQ_RX_ WINDOW. 
START is incremented modulo ARQ_BSN_MODULUS) such that the ARQ_RX_WINDOW_START variable points 
to the next lowest numbered ARQ block that has not been received or has been received with errors. The timer 
associated with ARQ_SYNC_LOSS_TIMEOUT shall be reset. 

As each block is received, a timer is started for that block. When the value of the timer for a block exceeds 
ARQ_RX_PURGE_TIMEOUT, the timeout condition is marked. When this occurs, ARQ_RX_WINDOW_START is 
advanced to the BSN of the next block not yet received after the marked block. Timers for delivered blocks remain 
active and are monitored for timeout until the BSN values are outside the receive window. 

When ARQ_RX_WINDOW_START is advanced, any BSN values corresponding to blocks that have not yet been 
received residing in the interval between the previous and current ARQ_RX_WINDOW_START value shall be marked 
as received and the receiver shall send an ARQ Feedback IE to the transmitter with the updated information. Any 
blocks belonging to complete SDUs shall be delivered. Blocks from partial SDUs shall be discarded. 

When a discard message is received from the transmitter, the receiver shall discard the specified blocks, advance 
ARQ_RX_WINDOW_START to the BSN of the first block not yet received after the BSN provided in the Discard 
message, and mark all not received blocks in the interval from the previous to new ARQ_RX_WINDOW_START 
values as received for ARQ feedback IE reporting. 

For each ARQ block received, an acknowledgment shall be sent to the transmitter. Acknowledgment for blocks outside 
the sliding window shall be cumulative. Acknowledgments for blocks within the sliding window may be either for 
specific ARQ blocks (i.e. contain information on the acknowledged ARQ block numbers), or cumulative (i.e. contain 
the highest ARQ block number below which all ARQ blocks have been received correctly) or a combination of both 
(i.e. cumulative with selective). Acknowledgments shall be sent in the order of the ARQ block numbers they 
acknowledge. The frequency of acknowledgement generation is not specified here and is implementation dependent. 

A MAC SDU is ready to be handed to the upper layers when all of the ARQ blocks of the MAC SDU have been 
correctly received within the time-out values defined. 

When ARQ_DELIVER_IN_ORDER is enabled, a MAC SDU is handed to the upper layers as soon as all the ARQ 
blocks of the MAC SDU have been correctly received within the defined time-out values and all blocks with sequence 
numbers smaller than those of the completed message have either been discarded due to time-out violation or delivered 
to the upper layers. 

When ARQ_DELIVER_IN_ORDER is not enabled, MAC SDUs are handed to the upper layers as soon as all blocks of 
the MAC SDU have been successfully received within the defined time-out values. 

The actions to be taken by the receiver state machine when an ARQ Reset message is received are provided in figure 4. 
The actions to be taken by the receiver state machine when it wants to initiate a reset of the transmitter ARQ state 
machine are provided in figure 5. Synchronization of the ARQ state machines is governed by a timer managed by the 
receiver state machine. Each time ARQ_RX_WINDOW_START is updated, the timer is set to zero. When the timer 
exceeds the value of ARQ_SYNC_LOSS_TIMEOUT the receiver state machine shall initiate a reset of the connection's 
state machines as described in figure 5. 
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Figure 3: ARQ block reception 

5.4.5 Resetting the ARQ state machine 

Synchronization of the ARQ state machines is governed by timers managed by the transmitter and receiver state 
machine. Each time ARQ_TX_WINDOW_START is updated, the transmitter timer is reset (set to zero). Each time 
ARQ_RX_WINDOW_START is updated, the transmitter timer is reset. 

When the timer exceeds the value of ARQ_SYNC_LOSS_TIMEOUT the state machine shall initiate the ARQ Reset 
process for that connection. The process of executing an ARQ Reset on a connection is shown in figures 4 and 5. 



£75/ 



48 



ETSI TS 102 178 VI .2.1 (2005-01) 



Wait for 
_^ ARQ Reset message 

with Type==OxO 



ARQ Reset with 
Type==OxO 



Disable 
transmi ssion 



ARQ Reset message 
Type =0x1 



Wait for 

ARQ Reset message 

with Type==0x2 




Error : 
Re-initialize MAC 



Discard SOUS with 
Tx-ed fragments 



Enable 
transmission 



Initiate Reset 
of ARQ 



ARQ Reset message 
Type =0x0 



Disable 
transmission 



Set T22 



Wait for 

ARQ Reset message 

with Type==Oxl 



ARQ Reset with 
Type==Oxl 



Clear T22 



ARQ_RX_WINDOW_START 



Discard incomplete 
SDUs 



Enable 
transmission 



ARQ Reset message 
Type =0x2 



(f Done J) 




Figure 4: Receiver initiated ARQ Reset 
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Figure 5: Transmitter initiated ARQ Reset 



5.5 ARQ service flow TLVs 

The following TLV encodings shall be available. 
ARQ SUPPORT: 

• The ARQ SUPPORT indicates whether or not ARQ is supported by the system. When the system supports 
ARQ, this TLV shall be included in the REG-REQ by the SS whereas the BS shall indicate acceptance or 
rejection of the ability. ARQ shall be available for connections only if both sides support it. 

ARQ ENABLE: 

• The ARQ ENABLE TLV indicates whether or not ARQ is available for the connection that is being setup. The 
DSA-REQ shall contain the request to use ARQ or not. The DSA-RSP message shall contain the acceptance or 
rejection of the request. ARQ shall be enabled for this connection only if both sides support it. When a 
DSA-REQ is issued by the BS, the use of ARQ may be mandated for the requested connection (if ARQ 
availability was confirmed during registration). In that case, the SS shall either reject the connection or accept 
the connection with ARQ. 
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ARQ WINDOW SIZE: 



• This parameter is negotiated upon connection setup. The DSA-REQ/DSC-REQ message shall contain the 

suggested value for this parameter. The DSA-RSP/DSC-RSP message shall contain the confirmation value or 
an alternate value for this parameter. The smaller of the two shall be used as the actual 
ARQ_WINDOW_SIZE. 

ARQ RETRY TIMEOUT: 



• 



• 



The ARQ retry timeout should account for the transmitter and receiver processing delays and any other delays 
relevant to the system. This is achieved through the use of the following two TLVs: 

ARQ_TX_DELAY: This is the total estimated transmitter delay, including sending (e.g. MAC PDUs) 
and receiving (e.g. ARQ feedback) delays and other implementation dependent processing delays. If the 
transmitter is the BS, it may include other delays such as scheduling and propagation delay. 

ARQ_RX_DELAY: This is the total estimated receiver delay, including receiving (e.g. MAC PDUs) and 
sending (e.g. ARQ feedback) delays and other implementation dependent processing delays. If the 
receiver is the BS, it may include other delays such as scheduling and propagation delay. 

The DSA-REQ and DSA-RSP messages shall contain the values for these parameters, where the receiver and 
transmitter each declare their capabilities. When the DSA handshake is completed, each party shall calculate: 



ARQ_RETRY_TIMEOUT = ARQ_TX_DELAY + ARQ_RX_DELAY (13) 

ARQ BLOCK LIFETIME: 

• The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_BLOCK_LIFETIME value shall be 
considered infinite. 

ARQ_SYNC_LOSS_TIMEOUT: 

• The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_SYNC_LOSS_TIMEOUT value shall 
be considered infinite. 

ARQ_DELIVER_IN_ORDER: 

• The transmitter shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter. This TLV indicates whether or not data is to be delivered by the receiving MAC to its client 
application in the order in which the data was handed off to the originating MAC. 

ARQ_RX_PURGE_TIMEOUT: 

• The BS shall set this parameter. The DSA-REQ or DSA-RSP messages shall contain the value of this 
parameter as set by the BS. If this parameter is set to 0, then the ARQ_RX_PURGE_TIMEOUT value shall be 
considered infinite. 
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Table 62: ARQTLVs 



Name 


Type 


Length 


Value 


Scope 


ARQ_SUPPQRT 


5.21 


1 


0: No ARQ support capability 

1 to 254: IVIax. simultaneous connections for 

which ARQ can be supported 
255: 255 or more simultaneously 

supportable ARQ connections 


REG-REQ 
REG-RSP 


ARQ_ENABLE 


[24/25]. 11 


1 


= ARQ not support 

1 = ARQ supported 

2 = ARQ mandated (BS in DSA-REQ only) 


DSA-REQ 
DSA-RSP 


ARQ_WINDOW_SIZE 


[24/25]. 12 


2 


1 -{ARQ_BSN_MQDULUS/2) 


DSx-REQ 
DSx-RSP 


ARQ_TX_DELAY 


[24/25]. 13 


2 


Estimated transmitter delay 
to 655 350 (10 |js granularity) 


DSA-REQ 
DSA-RSP 


ARQ_RX_DELAY 


[24/25]. 22 


2 


Estimated receiver delay 

to 655 350 (10 |js granularity) 


DSA-REQ 
DSA-RSP 


ARQ_BLQCK_LIFETIME 


[24/25]. 17 


2 


= Infinite 

1 to 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_SYNC_LOSS_TIMEOUT 


[24/25]. 19 


2 


= Infinite 

1 to 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_DELIVER_IN_QRDER 


[24/25]. 20 


1 


= Order of delivery is not preserved 

1 = Qrder of delivery is preserved 


DSA-REQ 
DSA-RSP 


ARQ_RX_PURGE_TIMEOUT 


[24/25]. 21 


2 


= Infinite 

1 to 655 350 (10 MS granularity) 


DSA-REQ 
DSA-RSP 


ARQ_BLQCK_SIZE 


[24/25].22 


1 


Length of ARQ block, bytes 


DSA-REQ 
DSA-RSP 



Mesh topology support 



6.1 



Introduction 



The main difference between the PMP and optional Mesh modes is that in the PMP mode, traffic only occurs between 
the BS and SSs, while in the Mesh mode traffic can be routed through other SSs and can occur directly between SSs. 
Depending on the transmission protocol algorithm used, sharing of channel resources can be done on the basis of 
equality using distributed scheduling, or on the basis of superiority of the mesh BS, which effectively results in 
centralized scheduling, or on a combination of both. 

Where optional mesh systems are addressed, a system consists of an MAC and PHY implementation with at least two 
mesh nodes communicating via a multipoint-to-multipoint radio air interface, along with the interfaces to external 
networks and services transported by the MAC and PHY. 

Within a mesh network, a system that has a direct connection to backhaul services outside the mesh network, is termed 
a mesh BS. All the other systems of a mesh network are termed mesh SS. In general, the systems of a mesh network are 
termed nodes. Within mesh context, uplink and downlink are defined as traffic in the direction of the mesh BS and 
traffic away from the mesh BS respectively. 

The other three important terms of mesh systems are neighbour, neighbourhood and extended neighbourhood. The 
stations with which a node has direct links are called neighbours. Neighbours of a node shall form a neighbourhood. A 
node's neighbours are considered to be "one hop" away from the node. An extended neighbourhood contains, 
additionally, all the neighbours of the neighbourhood. 

Using distributed scheduling, all the nodes including the mesh BS shall coordinate their transmissions in their two-hop 
neighbourhood and shall broadcast their schedules (available resources, requests and grants) to all their neighbours. 
Optionally the schedule may also be established by directed un-coordinated requests and grants between two nodes. 
Nodes shall ensure that the resulting transmissions do not cause collisions with the data and control traffic scheduled by 
any other node in the two-hop neighbourhood. There is no difference in the mechanism used in determining the 
schedule for downlink and uplink. 
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In the mode of operation with centralized scheduHng, resources are granted in a more centralized manner. The mesh BS 
shall gather resource requests from all the mesh SSs within a certain hop range. It shall determine amount of granted 
resources for each link in the network both in downlink and uplink, and communicates these grants to all the mesh SSs 
within the hop range. The grant messages do not contain the actual schedule but each node shall compute it by using the 
predetermined algorithm with given parameters. 

All the communications are in the context of a link, which is established between two nodes. One link shall be used for 
all the data transmissions between the two nodes. QoS is provisioned over links on a message by message basis. No 
service or QoS parameters are associated with a link but each unicast message has service parameters in the header. 
Traffic classification and flow regulation are performed at ingress node by upper-layer classification/regulation 
protocol. The service parameters associated with each message shall be communicated together with the message 
content via the MAC SAP. 

Mesh systems typically use omni directional or 360° steerable antennas, but can also be co-located using sector 
antennas. At the edge of the coverage area of the mesh network, where only a connection to a single point is needed, 
even highly directional antennas can be used. 



6.2 Addressing and connections 



Each node shall have a 48-bit universal MAC address. The address uniquely defines the node from within the set of all 
possible vendors and equipment types. This address is used during the network entry process and as part of the 
authorization process by which the candidate node and the network verify the identity of each other. 

When authorized to the network the candidate node shall receive a 16-bit Node Identifier (Node ID) upon a request to 
the mesh BS. Node ID is the basis for identifying nodes during normal operation. The Node ID is transferred in the 
Mesh subheader, which follows the Generic MAC header, in both unicast and broadcast messages. 

For addressing nodes in the local neighbourhood, 8-bit link identifiers (Link IDs) shall be used. Each node shall assign 
an ID for each link it has established to its neighbours. The Link IDs are communicated during the Link Establishment 
process as neighbouring nodes establish new links. The Link ID is transmitted as part of the CID in the Generic MAC 
header in unicast messages. The Link IDs shall be used in distributed scheduling to identify resource requests and 
grants. Since these messages are broadcast, the receiver nodes shall be able to identify the schedule of their own using 
both the transmitter's Node ID in the Mesh subheader, and the Link ID in the MSH-DSCH payload. 

After entering the network, a node can establish links with nodes other than its sponsor by following the secure process 
as defined in table 63. This process uses the MSH-NCFG Neighbour Link Establishment IE (see table 48). 

1) Node A sends a challenge (action code = 0x0) containing: 

HMAC{ Operator Shared Secret, frame number. Node ID of node A, Node ID of node B } (14) 

in which the Operator Shared Secret is a private key obtained from the provider (which is also used to enter the 
network) and the frame number is the last known frame number in which Node B send a MSH-NCFG 

message. 

2) Node B, upon reception, computes the same value (it may also attempt some earlier frame numbers in which it 
sent MSH-NCFG messages, in case node A missed the last of its MSH-NCFGs) as above and compares. If the 
values do not match, a rejection (action code = 0x3) is returned. If a match is achieved. Node B sends, 
implicitly accepting the link, a challenge response (action code = 0x1) containing: 

HMAC{Operator Shared Secret, frame number. Node ID of node B, Node ID of node A} (15) 

in which the frame number is the frame number in which Node A sent the MSH-NCFG message with 
challenge. It also randomly selects and includes an unused link ID, which shall from this point forward 
indicate the link from node B to node A. 

3) Node A, upon reception, computes the same value as above and compares. If the values do not match a 
rejection (action code = 0x3) is returned. If a match is achieved. Node A sends an Accept. It also randomly 
selects and includes an unused link ID, which shall from this point forward indicate the link from node A to 
node B. 
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Table 63: Link establishment 



Node A 




NodeB 


Send MSH-NCFG 






Neighbour Link Establishment IE 






Action Code = Challenge 


Challenge 


— >• 

If (HIVIAC match (see equation 14)) 
send MSH-NCFG 
Neighbour Link Establishment IE 
Action Code = Challenge Response 




< Challenge Response - 


newLinklDB^A 


If (HIVIAC match (see equation 15)) 






send MSH-NCFG 






Neighbour Link Establishment IE 






Action Code = Accept 






new Link ID A -^ B 




■w 







The Connection ID in mesh mode is specified as shown in table 64 to convey broadcast/unicast, service parameters and 
the link identification. 

Table 64: Connection ID 



Syntax 


Size 


Notes 


CIDO { 






if (Xmt Link ID == OxFF) { 






Logical Network ID 


8 bits 


0x00 All-net Broadcast 


} else { 






Type 


2 bits 


0x0 MAC Management 

0x1 IP 

0x2 to 0x3 Reserved 


Reliability 


1 bit 


0x0 No retransmissions 
0x1 Up to 4 retransmissions 


Priority/Class 


3 bits 


Indicates message class. 


Drop Precedence 


2 bits 


Messages with larger Drop Precedence shall have 
higher dropping likelihood during congestion. 


} 






Xmt Link ID 


8 bits 


OxFF MAC management broadcast 


} 







6.3 



MAC service definition 



6.3.1 Primitives 

The following primitives are supported at the MAC Service Access Point in mesh mode: 
MAC_CREATE_CONNECTION.indication. 
MAC_CHANGE_CONNECTION.indication. 
MAC_TERMINATE_CONNECTION.request. 
MAC_TERMINATE_CONNECTION.indication. 
MAC_DATA.request. 
MAC_DATA.indication. 
MAC_FORWARDING_UPDATE.request. 
MAC FORWARDING UPDATE.indication. 
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In mesh mode none of the actions cause the initiating CS to send a REQUEST primitive to its MAC sublayer. They are 
either indications of the results from the processes handled by the MAC CPS management entity, or data delivery 
actions needed to convey information to the peer CS. 

6.3.2 MAC_CREATE_CONNECTION. indication 

Function: 

• This primitive is issued by a MAC entity to the CS, to report a new link established to a neighbour node. 
Generation: 

• This primitive is generated whenever a new link has been established to a neighbour node. 
Effect of receipt: 

• The receipt of the primitive is an indication to the CS that a link to the given neighbour node is up and can be 
used for data delivery. 

Semantics: 

MAC_CREATE_CONNECT ION. indication 
{ 

CID, 

max length, 

service flow parameters, 
encryption flag 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

• The max length parameter specifies the maximum length of SDUs that are allowed over the link. 

• The service flow parameters include information on: 

Data rate (Mbps): 

■ Data rate associated with the burst profile for the physical link over which the connection is 
created. 

Transmit power (dB): 

■ Transmit power at the antenna port for the physical link over which the connection is created. 

• Estimate of packet error rate for 256-byte packets: 

The encryption flag specifies that the data carried over this link is encrypted, if ON, If OFF, then no 
encryption is used. 

6.3.3 MAC_CHANGE_CONNECTION. indication 

Function: 

• This primitive is issued by a MAC entity to the CS, to report new parameters of an existing link to a neighbour 
node. 

Generation: 

• This primitive is generated whenever parameters of an existing link has changed. 
Effect of receipt: 

• The CS shall take into account new link parameters in the use of the link. 
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Semantics: 

MAC_CHANGE_CONNECTION. indication 
{ 

CID, 

max length, 
service parameters, 
encryption flag 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

• The max length parameter specifies the maximum length of SDUs that are allowed over the link. 

• The service parameters include information on: 

Target data rate for the link in Mbps. 

Transmit energy for the link. 

Estimate of packet error rate for 256-byte packets. 

The encryption flag specifies that over this link encryption is possible, if ON, If OFF, then no encryption 
is possible. 

6.3.4 MAC_TERMINATE_CONNECTION. request 

Function: 

• This primitive is issued by a CS, to terminate an existing link to a neighbour node. 
Generation: 

• This primitive is generated to bring down an existing link to a neighbour node. 
Effect of receipt: 

• The receipt of the primitive causes the MAC to terminate the connection and report that to the MAC entity in 
the neighbour the link was to. 

Semantics: 

MAC_TERMINATE_CONNECTION. request 
{ 

CID 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

6.3.5 MAC_TERMINATE_CONNECTION. indication 

Function: 

• This primitive is issued by the MAC entity of the non-initiating side to indicate termination of the link to a 
neighbour node. 

Generation: 

• This primitive is generated by the MAC sublayer when it receives an indication in a MSH-NCFG message. 
Effect of receipt: 

• The receipt of the primitive is an indication to the CS that the link to the given neighbour node is down and 
cannot be used for data delivery. 
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Semantics: 

MAC_TERMINATE_CONNECTION. indication 
{ 

CID, 
} 

• The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

6.3.6 MAC_D ATA. request 

Function: 

• This primitive defines the transfer of data to the MAC entity from a convergence sublayer service access point. 
Generation: 

• This primitive is generated by a convergence sublayer whenever an MAC SDU is to be transferred to a peer 
entity. 

Effect of receipt: 

• The receipt of the primitive causes the MAC entity to process the MAC SDU through the MAC sublayer and 
pass the appropriately formatted PDUs to the PHY layer for transfer to the peer MAC sublayer entity, using 
the Node ID specified. 

Semantics: 

MAC_DATA. request 



{ 



CID, 

length, 

data, 

encryption flag 



The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

The length parameter specifies the length of the MAC SDU in bytes. 

The data parameter specifies the MAC SDU as received by the local MAC entity. 

The priority/class parameter embedded in the CID specifies priority class of the MAC SDU. 

The reliability parameter embedded in the CID specifies maximum number of transmission attempts at each 
hnk. 

The drop precedence parameter embedded in the CID indicates relative MSDU dropping likelihood. 

The encryption flag specifies that the data sent over this link is to be encrypted, if ON. If OFF, then no 
encryption is used. 

6.3.7 MAC_D ATA. indication 

Function: 

• This primitive defines the transfer of data from the MAC to the convergence sublayer. 
Generation: 

• This primitive is generated whenever an MAC SDU is to be transferred to a peer convergence entity. 
Effect of receipt: 

• The effect of receipt of this primitive by a convergence entity is dependent on the validity and content of the 
MAC SDU. 
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Semantics: 

MACJATA. request 



CID 

length, 

data, 

reception status, 

encryption flag 



• The CID is the Connection ID in Mesh as conveyed in the Generic MAC header. 

• The length parameter specifies the length of the MAC SDU in bytes. 

• The data parameter specifies the MAC SDU as received by the local MAC entity. 

• The reception status parameter indicates transmission success or failure for those PDUs received via the 
MAC_DATA.indication. 

6.3.8 MAC_FORWARDING_UPDATE.request 

Function: 

• This primitive defines the transfer of the centralized scheduling configuration to the MAC entity from a 
convergence sublayer service access point in the mesh BS. 

Generation: 

• This primitive is generated in the mesh BS whenever it has changed the schedule tree. 
Effect of receipt: 

• The receipt of this primitive causes the MAC to generate a MSH-CSCF message with the given information. 
The message shall be distributed to all the nodes listed in the tree. 

Semantics: 

• The parameters of the primitive are as follows: 

MAC_FORWARDING_UPDATE . request 
{ 

number of nodes, 

node parameters [number of nodes] 
} 

• The number of nodes parameter indicates number of nodes in the scheduling tree of this mesh BS. 

• The node parameters entry shall contain the following information: 

Node ID: The Node ID parameter indicates the node. 

number of children: The number of nodes parameter indicates number of children the given node. 

child parameters [number of children] . 

Each child parameters entry shall containing the following information: 

■ child index: The child index indicates index into the list of Node IDs; 

■ uplink burst profile: The uplink burst profile indicates burst profile of link to child node; 

■ downlink burst profile: The downlink burst profile indicates burst profile of link from child node. 
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6.3.9 MAC_FORWARDING_UPDATE.indication 

Function: 

• This primitive defines the transfer of the centralized scheduling configuration from the MAC to the 
convergence sublayer. 

Generation: 

• This primitive is generated by the MAC sublayer at all the nodes, which have received the MSH-CSCF 
message, when new centralized schedule with revised schedule tree takes effect. 

Effect of receipt: 

• The receipt of this primitive synchronizes the forwarder and MAC scheduler to routing changes. 
Semantics: 

MAC_FORWARDING_UPDATE . indication 
{ 

Node ID self 
number of nodes, 

node parameters [number of nodes] 
} 

• The Node ID self indicates the Node ID of the node itself. 

• The number of nodes parameter indicates number of nodes in the scheduling tree of this mesh BS. 

• The node parameters entry shall contain the following information: 

Node ID: The Node ID parameter indicates the node. 

number of children: The number of nodes parameter indicates number of children the given node. 

child parameters [number of children] . 

Each child parameters entry shall contain the following information: 

■ child index: The child index indicates index into the list of Node IDs. 

■ uplink burst profile: The uplink burst profile indicates burst profile of link to child node. 

■ downlink burst profile: The downlink burst profile indicates burst profile of link from child node. 

6.4 MAC management message applicability 

When implementing the mesh mode, all clauses referring to the mesh mode in the standard shall apply as mandatory. 
Basic functionalities are mandatory for a mesh node as they are for a PMP node, except those that are stated as optional 
below. 

For a mesh-enabled system, the messages below and the corresponding functionality are always mandatory to 
implement: 

MSH-NCFG. 

MSH-NENT. 

MSH-DSCH. 

MSH-CSCH. 

MSH-CSCF. 

REG-REQ. 
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REG-RSP. 

PKM-REQ. 

PKM-RSP. 

SBC-REQ. 

SBC-RSP. 

TFTP-CPLT. 

TFTP-RSP. 

RES-CMD. 

For a mesh enabled system, the following messages and the corresponding functionality are mandatory/optional 
whenever they are correspondingly optional/mandatory for a PMP system: 

ARQ-Feedback. 

AAS-FBCK-REQ. 

AAS-FBCK-RSP. 

When operating in the mesh mode, the messages below and the corresponding functionality are not used. 

DL-MAP. 

DCD. 

DSC-ACK. 

DSC-REQ. 

DSC-RSP. 

DSD-RSP. 

DSX-RVD. 

UCD. 

UL-MAP. 

CLK-CMP. 

DBPC-REQ. 

DBPC-RSP. 

DREG-CMD. 

MCA-REQ. 

MCA-RSP. 

RNG-REQ. 

RNG-RSP. 

DSA-ACK. 

DSA-REQ. 

DSA-RSP. 



£75/ 



60 ETSI TS 1 02 1 78 V1 .2.1 (2005-01 ) 



6.5 Network synchronization 



Network configuration (MSH-NCFG) and network entry (MSH-NENT) packets provide a basic level of communication 
between nodes in different nearby networks whether from the same or different equipment vendors or wireless 
operators. These packets are used to synchronize both centralized and distributed control mesh networks. 

This communication is used to support basic configuration activities such as: synchronization between nearby networks 
used (for instance, for multiple, co-located BSs to synchronize their uplink and downlink transmission periods), 
communication and coordination of channel usage by nearby networks, and discovery and basic network entry of new 
nodes. 

MSH-NCFG, MSH-NENT and MSH-DSCH can all assist a node in synchronizing to the start of frames. For these 
messages, the control subframe, which initiates each frame, is divided into transmit opportunities (see TS 102 177 [2]). 
The first transmit opportunity in a network control subframe may only contain MSH-NENT messages, while the 
remainder MSH_CTRL_LEN-1 may only contain MSH-NCFG messages. In scheduling control subframes, the 
MSH-DSCH_NUM transmit opportunities assigned for MSH-DSCH messages come last in the control subframe. The 
MSH-NCFG messages also contain the number of its transmit opportunity, which allows nodes to easily calculate the 
start time of the frame. 



6.5.1 Physical neighbour list 



All the basic functions like scheduling and network synchronization are based on the neighbour information all the 
nodes in the mesh network shall maintain. Each node (BS and SS) maintains a physical neighbourhood list with each 
entry containing the following fields: 

MAC Address 

• 48-bit MAC address of the neighbour. 
Hop Count 

• Indicates distance in hops of this neighbour from the present node. If a packet has been success-fully received 
from this neighbour recently (defined further below), it is considered to be 1 hop away. 

Node Identifier 

• 16-bit Number used to identify this node in a more efficient way in MSH-NCFG messages. 
XmtHoldoffTime 

• The minimum number of MSH-NCFG transmit opportunities that no MSH-NCFG message transmission is 
expected from this node after Next Xmt Time (see for detailed definition). 

Next Xmt Time 

• The MSH-NCFG transmit opportunity(ies) in which the next MSH-NCFG from this node is expected (see for 
detailed definition). 

Reported Flag 

• Set to TRUE if this Next Xmt Time has been reported by this node in a MSH-NCFG packet. Else set to 
FALSE. 

Synchronization hop count 



• 



This counter is used to determine superiority between nodes when synchronizing the network. Nodes can be 
assigned as master time keepers, which are synchronized externally (for example using GPS). These nodes 
transmit Synchronization hop count of 0. Nodes shall synchronize to nodes with lower synchronization hop 
count, or if counts are the same, to the node with the lower Node ID. 
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The Physical Neighbourhood List is updated as follows when a MSH-NCFG packet is received from a neighbour: 

• The hop count field in the Physical Neighbourhood List for the neighbour itself is set to 1 . The hop count field 
for other nodes listed in the MSH-NCFG message is set to Hops to Neighbour +2 (see table) unless they are 
already listed with a lower hop count. 

• The Next Xmt Time and Xmt Holdoff Time of the neighbour and all nodes listed in the MSH-NCFG are 
updated. 

• The "Reported Flag" for each entry in the Physical Neighbour table which was modified is set to FALSE. 

6.5.2 MSH-NCFG / MSH-NENT transmission cinannel and timing 

MSH-NCFG and MSH-NENT packets are scheduled for transmission during control subframes. So that all nearby 
nodes receive these transmissions, the channel used is cycled through the available channels in the band, with the 
channel selection being based on the Frame number. So, for Frame Number /, the channel is determined by the array 
lookup: 



NetConfigChannel = Logical channel list 



Frame Number 



Scheduling Frames x 4 + 1 



modNum Channels 



(16) 



where the Logical channel List and Scheduling Frames are derived from the MSH-NCFG:Network Descriptor 
(see table 44). 



6.5.2.1 



MSH-NCFG next transmission scheduling 



During the current Xmt Time of a node (i.e. the time slot when a node transmits its MSH-NCFG packet), the node uses 
the following pseudo-code procedure to determine its Next Xmt Time: 

Order its physical neighbour list by Next Xmt Time. 
For each entry in the neighbour list; 

Entry's Earliest Subsequent Xmt Time = Entry's Next Xmt Time + Entry's Xmt Holdoff Time 
Success = FALSE; 

TempXmtTime = Xmt Time + Xmt Holdoff Time 
While (Success == FALSE) do { 

Determine the eligible competing nodes, which is the set of all nodes in the physical- 
neighbour list for which: 

TempXmtTime cz Entry's Next Xmt Time eligibility interval (see equation 2); OR 
Entry's Earliest Subsequent Xmt Time < TempXmtTime. 



if ( MeshElection (TempXmtTime, MyNodelD, CompetingNodelDsList [ ; 

Set TempXmtTime equal to the next MSH-NCFG Xmt opportunity, 
else ; 

Success = TRUE 

Next Xmt Time =TempXmtTime . 



FALSE) 



The Mesh Election procedure determines whether the local node is the winner for a specific TempXmtTime among all 
the competing nodes. It returns TRUE if the local node wins or FALSE otherwise .The algorithm works as follows: 

boolean MeshElection (uint32 XmtTime, uintl6 MyNodelD, uint 16 NodelDList [ ] )) { 
uint32 nbr_smear__val, smear_vall, smear_val2; 
smear_vall =inline_smear (MyNodelD ^ XmtTime )); 
smear_val2 =inline_smear (MyNodelD iXmtTime ); 
For each Node ID nbrsNodelD in NodelDList Do { 

nbr_smear_val =inline_smear (nbrsNodelD ^ XmtTime ) ) ; 
if (nbr_smear_val >smear_vall ) ( 

return FALSE; //This node loses. 
} 

else if (nbr_smear„val ==smear_vall ) ( 
//1st tie-breaker. 

nbr_smear_val =inline_smear (nbrsNodelD IXmtTime ) ; 
if (nbr_smear_val >smear__val2 ) ( 

return FALSE; //This node loses. 
} 
else if (nbr_smear_val ==smear_val2 ) ( 
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//If we still collide at this point Break the tie based on MacAdr 
if ( (XmtTime is even && (nbrsNodelD >MyNodeID) ) | | 

(XmtTime is odd && (nbrsNodelD <MyNodeID ) ) ) { 

return FALSE; //This node looses. 



//This node won over this competing node 
}//End for all competing nodes 
//This node is winner, it won over all competing nodes, 
return TRUE; 
} 

// Convert a uniform 16-bit value to an uncorrelated uniform 16-bit hash value, uses mixing. 

uint32 inline_smear (uint 16 val) ( 

val += (val <<12) ; 

val ^= (val >>22) ; 

val += (val <<4) ; 

val ^= (val >>9) ; 

val += (val <<10) ; 

val ^= (val >>2) ; 

val += (val <<7) ; 

val "= (val >>12) ; 

return (val) ; 
} 

6.5.2.2 MSH-NENT next transmission scheduling 

The NetEntry scheduling protocol provides the upper layer protocol an unreliable mechanism to access the NetEntry 
slot(s), so that new nodes, which are not yet fully-functional members of the network, can communicate with the 
fully-functional members of the network. 

In the NetEntry slots new nodes shall transmit MSH-NENT messages using the following two step procedure: 

1) The initial MSH-NENT packet with request IE is sent in a random, contention-based fashion in a free network 
entry transmission slot in the immediately following MSH-NENT transmission opportunity after the targeted 
sponsor sends a MSH-NCFG. with sponsored MAC address 0x000000000000. 

2) After the sponsor advertises the new nodes MAC Address in a MSH-NCFG message, the new node may send 
a MSH-NENT in the immediately following MSH-NENT transmission opportunity. 

A new node uses the algorithm specified by the following pseudocode to access NetEntry transmission slots: 

/*Variable Definitions */ 

Pkt *MSH-NENT_MsgQ =NULL; //MSH-NENT Message queue 

uint SponsorsState =UNAVAILABLE; //SponsorsState and OthersState record the NetEntry 

uint OthersState =BUSY; 

// Address in the MSH-NCFG packet form the sponsor or other nodes, 

// which can be used to determine the availability of the next NetEntry transmission opportunity 

//SponsorsState can be UNAVAILABLE, AVAILABLE and POLLING. 

//OthersState can be AVAILABLE and BUSY. 

uint OthersMaxMacAdr =OxFFFFFFFF; 

uint OthersMinMacAdr =0x00000000; 

void RecvOutgoingMSH-NENT_Msg (Pkt *MSH-NENT_Msg) { 

MSH-NENT_MsgQ->enqueue (MSH-NENT_Msg) ; 
} 

void RecvIncomingMSH-NCFG_Msg (Pkt *MSH-NCFG_Msg) { 

if (MSH-NCFG_Msg->sourceMacAdr ==sponsorsMacAdr) { 
switch (MSH-NCFG_Msg->NetEntryAddress) 
{ 

case 0x000000000000: SponsorsState =AVAILABLE; break; 
case myMacAdr: SponsorsState =POLLING; break; 

default: break; 

} 
} else { 

switch (MSH-NCFG_Msg->NetEntryAddress) 
{ 

case OxOOOOOOOOOOOO:break; 
default: OthersState =BUSY; 

if (OthersMaxMacAdr <MSH-NCFG_Msg->NetEntryAddress) 

OtherMaxMacAdr=MSH-NCFG_Msg->NetEntryAddress; 
if (OthersMinMacAdr >MSH-NCFG_Msg->NetEntryAddress ) 



£75/ 



63 ETSI TS 1 02 1 78 V1 .2.1 (2005-01 ) 

OtherMinMacAdr =MSH-NCFG_Msg->NetEntryAddress; 



) 



void NetworkControlSubf rameStart ( ) ( 
boolean xmt =FALSE; 
if (MSH-NENT_MsgQ->qLength ) { 

if (SponsorsState ==AVAILABLE) { 
if (OthersState !=BUSY) 

xmt =TRUE; 
} 
else if (SponsorsState ==POLLING) { 
if (OthersState !=BUSY) 

xmt =TRUE; 
else if ( ( (mayMacAdr >OthersMaxMacAdr) && (even supperframe) ) I I 
( (mayMacAdr <OthersMinMacAdr) && (odd supperframe))) 
xmt =TRUE; 
} 
} 
if (xmt) { 

Pkt*MSH-NENT_Msg =MSH-NENT_MsgQ->getHead ( ) ; 
MSH-NENT_MsgQ->dequeue (MSH-NENT_Msg) ; 
SendOutPkt (MSH-NENT_Msg, nextNetEntryslot ) ; 
} 

SponsorsState =UNAVAILABLE; 
OthersState =AVAILABLE; 
Other sMaxMacAdr =0x000000000000; 
Other sMinMacAdr =OxFFFFFFFFFFFF; 
} 

The individual subroutines are triggered by the transmission of a MSH-NENT packet, the reception of a MSH-NCFG 
packet and the start of a NetworkControl Subframe respectively. 

6.6 Network entry and synchronization 

Node initialization and network entry procedures in mesh mode are in some aspects different from those in PMP mode. 
A new node entering the mesh network obeys the following procedures. The whole entry pro-cess to the stage when the 
node can start scheduled transmissions can be divided into the following phases: 

1) Scan for active network and establish coarse synchronization with the network. 

2) Obtain network parameters (from MSH-NCFG messages). 

3) Open Sponsor Channel. 

4) Node authorization. 

5) Perform registration. 

6) Establish IP connectivity. 

7) Establish time of day. 

8) Transfer operational parameters. 

Each node shall contain a 48-bit universal MAC address assigned during the manufacturing process. This is used to 
identify the node to the various provisioning servers during initialization and whenever performing authentication with 
a neighbour node. 

6.6.1 IVIAC management message tunnelling 

In Mesh networks during network entry certain MAC Message protocols take place between entities separated by 
multiple hops. In these cases the Sponsor Node shall relay the MAC Messages from the new node acting as the SS to 
the peer performing the duties of the PMP BS. The sponsor shall also relay the messages from the BS entity to the new 
node. 
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The Sponsor shall tunnel the MAC Messages received from the New Node (SS) listed in table 65 over UDP as shown in 
figure 6. to the entity performing the BS part of the protocol. The UDP source and destination port used for tunnelled 
messages shall be equal to 80216_UDP_PORT. The sponsor shall also extract the MAC messages from the UDP 
packets arriving from the BS entity and transmit them over the air to the New Node. 

Table 65: MAC management message tunnelling over UDP 



Message 


Sponsor action 


Direction of 
message 


PKM-REQ: Auth Request 


Tunnel 


SS to BS 


PKM-REQ: Auth Info 


Tunnel 


SS to BS 


PKM-REQ: Auth Reply 


Extract 


BS to SS 


PKM-REQ: Auth Reject 


Extract 


BS to SS 


REG-REQ 


Tunnel 


SS to BS 


REG-RSP 


Extract 


BS to SS 


DSA-REQ 


Tunnel 


SS to BS 


DSA-RSP 


Extract 


BS to SS 


DSA-ACK 


Tunnel 


SS to BS 



IP header(s) 


UDP header 


Tunnel Subheader 


Message including headers 



Figure 6: MAC management message tunnelling message format 

The format of the Tunnel Subheader is defined in table 66. 

Table 66: Tunnel Subheader format 



Syntax 


Size 


Notes 


Tunnel Subheader () { 






Type 


8 bits 


= Reserved 

1 = HiperMAN MAC header 

2 to 255 = Reserved 


} 







Also, MAC messages may need to be tunnelled end to end in cases when the protocol takes place between peers 
separated by several hops. The packet format in figure 6 shall be used in these cases with the Tunnel Subheader format 
defined in table 66. 

6.6.2 Scanning and coarse synchronization to network 

On initialization or after signal loss, the node shall search for MSH-NCFG messages to acquire coarse synchronization 
with the network. Upon receiving a MSH-NCFG message the node acquires the network time from the Timestamp 
field. The node may have non-volatile storage in which all the last operational parameters are stored and shall first try to 
re-acquire coarse synchronization with the network. If this fails, it shall begin to continuously scan the possible 
channels of the frequency band of operation until a valid network is found. 

Once the PHY has achieved synchronization, the MAC Sublayer shall attempt to acquire network parameters. At the 
same time the node shall build a Physical Neighbour List (see clause 6.5.1). 
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Figure 7: Synchronization and networic entry - new node I 



6.6.3 Obtaining network parameters 



A node shall remain in synchronization as long as it receives MSH-NCFG messages. A node shall accumulate MSH- 
NCFG messages at least until it receives a MSH-NCFG message from the same node twice and until it has received a 
MSH-NCFG Network Descriptor with an operator ID matching (one of) its own if it has any. In parallel the new node 
shall update its Physical Neighbour List (see clause 6.5.1) from the acquired information. 

From the established physical neighbour list, the new node shall select a potential Sponsoring Node out of all nodes 
having the Logical Network ID of the node for which it found a suitable Operator ID. The new node then shall then 
synchronize its time to the potential sponsor assuming propagation delay after which it shall send a MSH-NENT 
NetEntryRequest including the Node ID of the potential sponsor. To determine a suitable transmission time, the node 
shall adhere to clause 6.5.2.2. 

Until the node has obtained a unique Node ID, it shall use temporary Node ID (0x0000) as Transmitter's Node ID in all 

transmissions. 

Once the Candidate Node has selected a Sponsoring Node, it shall use the Sponsoring Node to negotiate basic 
capabilities and to perform authorization. For that purpose the Candidate Node shall first request the Sponsoring Node 
to open Sponsor Channel for a more effective message exchange. 
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6.6.4 Opening sponsor channel 



Once the new node has selected one of its neighbours as the candidate Sponsoring Node it becomes a Candidate Node. 
To get further in the initialization procedure the Candidate Node shall request the candidate Sponsoring Node to 
establish a temporary schedule which could be used for further message delivery during the Candidate Node 
initialization. The temporary schedule requested is termed Sponsor Channel. 

The process is initiated by the Candidate Node which transmits a MSH-NENT NetEntryRequest message (a 
MSH-NENT message with Type set to 0x2) to the Sponsoring Node. 

Upon reception of the MSH-NENT NetEntryRequest message with the Sponsor Node ID equal to Node ID of its own, 
the candidate Sponsoring Node shall assess the request and either opens the Sponsor Channel or rejects the request. The 
response is given in a MSH-NCFG message with an Embedded Data as defined in clause 4.3.18.3. If the candidate 
Sponsoring Node does not advertise the Candidate Node's MAC address in the sponsor's next MSH-NCFG 
transmission, then the procedure is repeated MSH_SPONSOR_ATTEMPTS times using a random backoff between 
attempts. If these attempts all fail, then a different Candidate Sponsoring Node is selected and the procedure repeated 
(including re-initializing coarse network synchronization). If the selected candidate Sponsoring Node does advertise the 
Candidate Node's MAC address, it shall continue to advertise this MAC address in all its MSH-NCFG messages until 
the sponsorship is terminated. 

Once the Candidate Node has received a positive response (a NetEntryOpen message) in from the candidate Sponsoring 
Node in the MSH-NCFG message, it shall acknowledge the response by transmitting a MSH- NENT NetEntryAck 
message (a MSH-NENT message with Type set to 0x1) to the Sponsoring Node at the first following network entry 
transmission opportunity. Before that the Candidate Node shall perform fine time synchronization. It makes a correction 
to its transmission timing by the Estimated propagation delay indicated in the embedded MSH-NCFG NetEntryOpen 
message. 

If the Sponsoring Node accepted the request and opened a Sponsor Channel, the channel is ready for use immediately 
after the transmission of the acknowledgement message. At the same the candidate Sponsoring Node becomes the 
Sponsoring Node. 

If the candidate Sponsoring Node embedded a MSH-NCFG NetEntry Reject, the new node shall perform the following 
action based on the rejection code: 

0x0: Operator Authentication Value Invalid 

The Candidate Node shall select a new candidate Sponsoring Node with a different operator ID. 

0x1: Excess Propagation delay 

The Candidate Node shall repeat its MSH-NENT:NetEntryRequest in the following network entry 
transmission opportunity to the same candidate Sponsoring Node. 

0x2: Select new sponsor 

The Candidate Node shall select a new candidate Sponsoring Node. 

If the candidate Sponsoring Node embedded neither MSH-NCFG NetEntryOpen nor MSH-NCFG NetEntryReject, the 
Candidate Node shall wait (with timeout time T2), for the next MSH-NCFG with NetEntryOpen from the candidate 
Sponsoring Node and resend the MSH-NENT NetEntryRequest on timeout. 

The Candidate Node and the Sponsoring Node use the schedule indicated in the NetEntryOpen message to perform 
message exchanges described in clauses 6.6.5 through 6.6.10. After this is completed, the Candidate Node shall 
terminate the entry process by sending a MSH-NENT NetEntryClose message to the Sponsoring Node in the network 
entry transmission immediately following a MSH-NCFG transmission from the Sponsoring Node, which shall Ack 
termination with MSH-NCFG NetEntryAck. 
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Figure 8: Synchronization and networl^ entry - new node II 
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Figure 9: Synchronization and networit entry - sponsor node 
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Table 67 displays the message transfer sequence during a successful network entry without repetitions or time-outs. 

Table 67: Network entry successful message exchange 



Sponsor node 








New node 


Nodes in network routinely advertise 
network with 
IVISH-NCFGiNetwork Descriptor 

[IVISH-NENT NetEntryRequest with own 

Node ID] 

Send NetEntryReject or NetEntryOpen 

with new node's MAC address and 

schedule allocation for higher layer 

authentication and configuration 

exchange 




MSH-NCFG: 




[detecting MSH-NCFG messages with 
Network Descriptor] 
Attempt to enter the network 

Send ACK to confirm schedule 


<— 


Network Descriptor 

MSH-NENT: 
~ NetEntryRequest 

MSH-NCFG: 




NetEntryOpen 
MSH-NENT: 






NetEntryAcK 




Security sublayer and basic capability exchange operations 


Acknowledge closure of sponsorship 

And drop new node's IVIAC address from 

subsequent MSH-NCFG messages 




MSH-NENT: 




After authentication and configuration, 
close entry procedure 

New node is now regular node in 
network 




NelEnlryClose 
MSH-NENT 






NetEntryAck 





6.6.5 Negotiating basic capabilities 

In Mesh Mode, basic capability negotiation is the same as for PMP systems and shall be performed after a logical link 
has been established. The node which requested the logical link shall act as the SS and initiate the SBC-REQ. 

6.6.6 Node Autinorization 

The new node shall perform authorization in an identical fashion as PMP systems. The new node shall act as the SS. 
The sponsor node upon reception of the Authent Info and Auth Request shall tunnel the messages as described in to the 
Authorization Node. The Authorization Node, acting as the BS, shall verify the SS Certificate of the new node and 
determine whether the new node is authorized to join the Network. Upon receiving tunnelled PKM-RSP MAC 
Messages from the Authorization Node the Sponsor shall forward the messages to the new node. 

6.6.7 Node Registration 

Registration is the process by which a node is assigned its Node ID. The sponsoring node upon reception of the 
REG-REQ shall tunnel the message as described in clause 6.6.1 to the Registration Node. Upon receiving tunnelled 
REG-RSP MAC Messages from the Registration Node the Sponsor shall forward the messages to the new node. The 
new node shall follow the procedure in figure 10. The Registration Node shall follow the procedure in figure 11. 
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Figure 10: Registration - candidate node 
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Figure 11: Registration - registration node 



6.6.8 Establishing IP connectivity 



The node shall acquire an IP address using DHCP in a fashion identical to PMP systems. However, the procedure shall 
take place over the Sponsor Channel. 
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6.6.9 Establishing time of day 



The node shall retrieve the time of day in a fashion identical to PMP. However, the messages shall be carried over UDP 
in the Sponsor Channel. 



6.6.1 Transfer of operational parameters 



After successfully acquiring an IP address via DHCP the node shall download a parameter file using TFTP in a fashion 
identical to PMP systems. However, the node shall use the Sponsor Channel instead of the Secondary Management 
connection. 

Upon receiving tunnelled REG-RSP MAC Messages from the Provisioning Node the Sponsor shall forward the 
messages to the Candidate Node. 

The following additional configuration file encodings are available: 



Name 


Type 


Length 


Value 


Authorization Node 


22 


4 or 16 


IP Address of tlie Autliorization Node 


Registration Node 


23 


4 or 16 


IP Address of the Registration Node 


Provisioning Node 


18 


4 or 16 


IP Address of the Provisioning Node 



Using mesh, QoS is provisioned on a packet-by-packet basis using the Mesh CID. The connection-based QoS 
provisioning using the DSx messages are hence not used. A node obtains its AuthorizedQoSParamSet during the 
transfer of operational parameters. 

6.7 Privacy sublayer 

The privacy sublayer for Mesh mode is identical to that of PMP mode with the following exceptions. 

6.7.1 TEK exchange overview 

Upon achieving authorization, a Node starts for each Neighbour a separate TEK state machine for each of the S AIDs 
identified in the Authorization Reply message. Each TEK state machine operating within the Node is responsible for 
managing the keying material associated with its respective SAID. The Node is responsible for maintaining the TEKs 
between itself and all nodes it initiates TEK exchange with. Its TEK state machines periodically send Key Request 
messages to the Neighbours of the node, requesting a refresh of keying material for their respective SAIDs. 

The Neighbour replies to a Key Request with a Key Reply message, containing the BS's active keying material for a 
specific SAID. 

The Traffic Encryption Key (TEK) in the Key Reply is encrypted, using the node's public key found in the 
SS-Certificate attribute. 

Note that at all times the node maintains two active sets of keying material per SAID per neighbour. The life-times of 
the two generations overlap such that each generation becomes active halfway through the life of its predecessor and 
expires halfway through the life of its successor. A neighbour includes in its Key Replies both of an S AID's active 
generations of keying material. 

The Key Reply provides the requesting Node, in addition to the TEK, the remaining lifetime of each of the two sets of 
keying material. The receiving Node uses these remaining lifetimes to estimate when the Neighbour invalidates a 
particular TEK, and therefore when to schedule future Key Requests. The transmit regime between the initiating Node 
and the Neighbour provides for seamless key transition. 

6.7.2 Node Re-Authorization 

When re-authorizing with the network, the re-authorizing node shall tunnel the authorization messages as shown in 
figure 6 over UDP. 
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6.7.3 TEK usage 

For each of its SAIDs, the neighbour shall transition between active TEKs according to the following rules: 

• At expiration of the older TEK, the neighbour shall immediately transition to using the newer TEK for 
encryption. 

• The neighbour that generated the TEK shall use the older of the two active TEKs for encrypting traffic towards 
the Node that initiated the TEK. 

• The neighbour that generated the TEK shall be able to decrypt traffic from each node using either the older or 
newer TEK. 

For each of its authorized SAIDs, the initiator node shall use the newer of its two TEKs to encrypt traffic towards its 
neighbours with which it initiated a TEK exchange, and shall be able to decrypt traffic from the neighbour's traffic 
encrypted with either of the TEKs. 

6.7.4 Usage of operator shared key 

Each node shall be capable of maintaining two active Operator Shared Secrets. A node shall use the Operator Shared 
Secret to calculate a HMAC digest for the Key Request and Key Reply messages when exchanging TEKs with its 
neighbouring nodes. 

6.7.5 HMAC authentication l^eys and calculation of HMAC digests 

The HMAC_KEY_S shall be derived as follows: 

HM AC_KE Y_S = SHA(H_PAD_D I Operator Shared Secret) (17) 

where H_PAD_D = Ox3A repeated 64 times. 

HMAC digests calculated with the key HMAC_KEY_S shall be supported. When calculating the digest with this key 
the HMAC sequence Number in the HMAC tuple shall be equal to the Operator Shared Secret Sequence Number. 



6.8 Data scheduling 



Unlike the PMP mode, there are no clearly separate downlink and uplink subframes in the mesh mode. Each station is 
able to create direct communication links to a number of other stations in the network instead of communicating only 
with a BS. However, in typical installations, there will still be certain nodes which provide the BS function of 
connecting the mesh network to the backhaul links. In fact, when using mesh centralized scheduling (described below), 
these BS nodes perform much of the same basic functions as does the BS in PMP mode. Thus, the key difference is that 
in mesh mode all the SSs may have a direct links with other SSs. Further, there is no need to have direct link from a SS 
to the BS of the mesh network. This connection can be provided via other SSs. Communication in all these links shall 
be controlled by a centralized algorithm (either by the BS or "decentralized" by all nodes periodically), scheduled in a 
distributed manner within each node's extended neighbourhood, or scheduled using a combination of these. 



6.8.1 Distributed scheduling 



The stations with which a station has direct links are called neighbours and shall form a neighbourhood. A node's 
neighbours are considered to be "one hop" away from the node. A two-hop extended neighbourhood contains, 
additionally, all the neighbours of the neighbourhood. In the coordinated distributed scheduling mode, all the stations 
(BS and SSs) shall coordinate their transmissions in their extended two-hop neighbour-hood. 

The coordinated distributed scheduling mode uses some or the entire control portion of each frame to regularly transmit 
its own schedule and proposed schedule changes on a PMP basis to all its neighbours. Within a given channel all 
neighbour stations receive the same schedule transmissions. All the stations in a network shall use this same channel to 
transmit schedule information in a format of specific resource requests and grants. 

Coordinated distributed scheduling ensures that transmissions are scheduled in a manner that does not rely on the 
operation of a BS, and that are not necessarily directed to or from the BS. 
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Within the constraints of the coordinated schedules (distributed or centraHzed), uncoordinated distributed scheduHng 
can be used for fast, ad-hoc setup of schedules on a link-by-link basis. Uncoordinated distributed schedules are 
established by directed requests and grants between two nodes, and shall be scheduled to ensure that the resulting data 
transmissions (and the request and grant packets themselves) do not cause collisions with the data and control traffic 
scheduled by the coordinated distributed nor the centralized scheduling methods. 

Both the coordinated and uncoordinated distributed scheduling employ a three-way handshake. 

1) A MSH-DSCH:Request is made along with MSH-DSCH:Availabilities, which indicate potential slots for 
replies and actual schedule. 

2) A MSH-DSCH:Grant is sent in response indicating a subset of the suggested availabilities which fits, if 
possible, the request. The neighbours of this node not involved in this schedule shall assume the transmission 
takes place as granted. 

3) A MSH-DSCH:Grant is sent by the original requester containing a copy of the grant from the other party, to 
confirm the schedule to the other party. The neighbours of this node not involved in this schedule shall assume 
the transmission takes place as granted. 

The differences between coordinated and uncoordinated distributed scheduling is, that in the coordinated case, the 
MSH-DSCH messages are scheduled themselves in the control subframe in a collision free manner, whereas in the 
uncoordinated case, MSH-DSCH messages may collide. Nodes responding to a Request should, in the uncoordinated 
case, wait a sufficient number of minislots of the indicated Availabilities before responding with a grant, such that 
nodes listed earlier in the Request have an opportunity to respond. The Grant confirmation is sent in the minislots 
immediately following the first successful reception of an associated Grant packet. 

The relevance of the MSH-DSCH is solely defined by the message itself and entirely up to the station transmitting it. 



6.8.2 Centralized scheduling 



The schedule using centralized scheduling is determined in a more centralized manner than in the distributed scheduling 
mode. 

The network connections and topology are the same as in the distributed scheduling mode described in , but some 
portion of the scheduled transmissions for the SSs less than or equal to HOPRANGE_THRESHOLD hops from the BS 
shall be either defined by the BS or computed by the SSs themselves. HOPRANGE_THRESHOLD, may be determined 
at the system start up phase or may be dynamic according to considerations such as network density, the proximity of 
other BSs, and/or the dynamic characteristics of the traffic streams. 

In the basic form, the BS shall provide the schedule for all the SSs less than or equal to HOPRANGE_THRESHOLD 
hops from the BS. The BS determines the flow assignments from the resource requests from the SSs within the 
HOPRANGE_THRESHOLD hop range. Subsequently, the SSs themselves determine the actual schedule from these 
flow assignments by using a common algorithm that divides the frame proportionally to the assignments. Thus the BS 
acts just like the BS in a PMP network except that not all the SSs have to be directly connected to the BS and the 
assignments determined by the BS extends also to those SSs not directly connected to the BS but less than 
HOPRANGE_THRESHOLD hops from it. The SS resource requests and the BS assignments are both transmitted 
during the control portion of the frame. 

Centralized scheduling ensures that transmissions are coordinated to ensure collision-free scheduling over the links in 
the routing tree to and from the BS, typically in a more optimal manner than the distributed scheduling method for 
traffic streams (or collections of traffic streams which share links) which persist over a duration that is greater than the 
cycle time to relay the new resource requests and distribute the updated schedule. 

A simple example of the use of the centralized scheduling flow-mechanism in MSH-CSCH is provided. For the network 
in figure 12, the requested flows are shown. For simplicity of notation, the data rate is assumed to be the burst profile 
number. 

The link fractions shown in figure 13 are multiplied with 2^^°^^'^^^'^ Exponent+14 (ggg table 55) and with the Frame 
Duration, then rounded up to the nearest duration of a whole number of minislots required to transmit this fraction 
(including preamble). 
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Node ID: 
0x0666 




u 



^Node ID 
^0x02F0 




m 



Node ID: 
OxOlAB 




i Node ID Child Indexes 

0x0666 {I:[rui,rd,],2:[ru2,rd2]} 

1 0x02F0 {3:[r„3,rd3],4:[r„4,rd4]} 

2 OxOlAB { } 

3 0x0CD2 { } 

4 0X0123 {} 



C<i»f 



pode ID 
OxOCD2 




r ^Node ID: 
^■\rj 0x0123 




[ru,rd] is the burst profile, up and down 



Figure 12: MSH-CSCF schedule example 
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Figure 13: MSH-CSCH flow usage example 

The number of frames over which the CSCH schedule is valid is limited by the number of frames it takes to aggregate 
and distribute the next schedule. 

Each node uses the newly received schedule to compute its retransmission time (if eligible) and the last frame when a 
node will be receiving this schedule, as well as the time when the mesh BS sent it. To compute this, the node uses the 
routing tree from the last MSH-CSCF messages as modified by the link updates of the last MSH-CSCH message (which 
dictates the size of MSH-CSCH messages) and the following rules: 

The mesh BS transmits first in a new frame. 

Then, the eligible children of the mesh BS (i.e. nodes with hop count equal 1), ordered by their appearance in 
the routing tree, transmit. 

Then, the eligible children of the nodes from step 2 (i.e. nodes with hop count equal 2), also ordered by their 
appearance in the routing tree, transmit. 

. . .continue until all eligible nodes in the routing tree have transmitted. 

Nodes shall fragment their message if it does not fit entirely before the end of the control subframe and at least 
the preamble and one data symbol fit. 

All nodes are eligible to transmit the grant schedule, except those that have no children. 
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• If a node's order requires it to transmit immediately after receiving, a delay of MinCSForwardingDelay ^.s is 
inserted. 

Each node shall also compute the timing of the uplink requests. Uplink requests start in the last frame in which a node 
received the previous schedule. All nodes are eligible to transmit requests, except the mesh BS. The request 
transmission order is reverse in hopcount (i.e. largest hopcount first), but retains the transmission order as listed in the 
routing tree for nodes with the same hopcount. 

The number of frames over which the CSCH schedule is valid is limited by the number of frames it takes to aggregate 
and distribute the next schedule. The time between the first frame in which a node sends the request schedule and the 
last frame in which a node receives the new grant schedule marks the validity of the previous grant schedule 
(see figure 14). This validity time overrides the Frame schedule flag two frame usage at the end of the validity time. 
Note that MSH-CSCF messages may be sent after the last request is received and before the grant schedule is 
transmitted by the mesh BS. 

Validity of previous schedule 



Tree 
depth 




MinCSForwardDelav 



J-kJ- 



J-kJ- 



±-k^ 



±-KA. 



Control subframe 



Data subframe 



Figure 14: MSH-CSCH schedule validity 



MAC support of PHY 



A compliant device shall conform to MAC support of PHY mechanisms provided by clauses 6.3.7. as defined in 
IEEE P802. 16-2004 [1] with the following exceptions nominated bellow. AAS optional mode is included in the 
referenced clause. 



7.1 



Uplink timing 



Uplink timing is referenced from the beginning of the downlink subframe. The Allocation Start Time in the 
UL-MAP is referenced from the start of the downlink subframe and may be such that the UL-MAP references 
some point in the current or a future frame as provided by clause 6.3.7.5 in IEEE P802. 16-2004 [1]. The SS shall 
always adjust its concept of uplink timing based upon the Timing Adjustments sent in the RNG-RSP messages. 

n = (Rate* x Frame Duration) / 4 
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Figure 15: TDD frame structure 
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7.2 Uplink allocation 

For the PHY layer, the uplink bandwidth allocation map (UL-MAP) uses units of symbols and subchannels. 

8 Network Entry and Initialization 

The clause 6.3.9 from IEEE P802.16-2004 [1] shall apply to PMP systems network entry and initalization 
The following clause shall apply instead of clause 6.3.9.5 from IEEE P802. 16-2004 [1]. 

8.1 Initial ranging and automatic adjustments 

Ranging is the process of acquiring the correct timing offset and power adjustments such that the SS's transmissions are 
aligned to the BS receive frame for OFDM PHY, and received within the appropriate reception thresholds. The timing 
delays through the PHY shall be relatively constant. Any variation in the PHY delays shall be accounted for in the 
guard time of the uplink PHY overhead. 

8.1 .1 Contention based Initial ranging and automatic adjustments 

First, an SS shall synchronize to the downlink and learn the uplink channel characteristics through the UCD MAC 
management message. At this point, the SS shall scan the UL-MAP message to find an Initial Ranging Interval. The BS 
shall allocate an Initial Ranging Interval consisting of one or more transmission opportunities. For OFDM PHY, the size 
of each transmission opportunity shall be as specified by the UCD TLV, Ranging request opportunity size. 

For OFDM PHY, the SS shall put together a RNG-REQ message to be sent in an Initial Ranging Interval. The CID field 
shall be set to the non initialized SS value (zero). 

Ranging adjusts each SS's timing offset such that it appears to be collocated with the BS. The SS shall set its initial 
timing offset to the amount of internal fixed delay equivalent to collocating the SS next to the BS. This amount includes 
delays introduced through a particular implementation and shall include the downlink PHY interleaving latency, if any. 

When the Initial Ranging transmission opportunity occurs, the SS shall send the RNG-REQ message. Thus, the SS 
sends the message as if it were collocated with the BS. 

The SS shall calculate the maximum transmit signal strength for initial ranging, Pj^ jj^ MAX' fro^i- 

Ptx_ir_max = EIRxPiR,„,,x+ BS.EIRP - RSS (18) 

where the EIRxPlR,max and BS_EIRP are obtained from the DCD, and RSS is the measured RSSI, by the SS, as 
described in the respective PHY. 

In the case that the receive and transmit gain of the SS antennae are substantially different, the SS shall use the 
equation: 

Ptx_ir_max = EIRxPiR,n,,x + BS.EIRP - RSS +(Gr,_ss-Gtx_ss)- (19) 

Where: 

• Gjjx SS is the SS receive antenna gain. 

• Gjx SS is the SS transmit antenna gain. 

In the case that the EIRxPjj^ ^.^^ and/or BS_EIRP are/is not known, the SS shall start from the minimum transmit power 
level defined by the BS. 
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NOTE 1: The EIRxPjj^ ^.^^ is the maximum equivalent isotropic received power, which is computed for a simple 
single antenna receiver as RSSjj^ ^.^^ - GANT_BS_Rx, where the RSSjj^ ^.^^ is the received signal 
strength at antenna output and GANT_BS_Rx is the receive antenna gain. The BS_EIRP is the equivalent 
isotropic radiated power of the base station, which is computed for a simple single-antenna transmitter as 
Pj^+ GANT_BS_Tx, where P-p^is the transmit power and GANT_BS_Tx is the transmit antenna gain. 

For OFDM PHY, the SS shall send the RNG-REQ at a power level below Ptx_IR_MAX, measured at the antenna 
connector. If the SS does not receive a response, the SS shall resent the RNG-REQ at the next appropriate Initial 
Ranging transmission opportunity at one step higher power level. If the SS receives a response containing the frame 
number in which the RNG-REQ was transmitted, it shall consider the transmission attempt unsuccessful but implement 
the corrections specified in the RNG-RSP and issue another RNG-REQ message after the appropriate backoff delay. 

If the SS receives a response containing its MAC Address, it shall consider the RNG_RSP reception successful. 

When BS detects a transmission in the ranging slot that it is unable to decode, it may respond by transmitting a 
RNG-RSP that includes transmission parameters but identifies the frame number and frame opportunity when the 
transmission was received instead of the MAC Address of the transmitting SS. 

Once the BS has successfully received the RNG-REQ message, it shall return a RNG-RSP message using the initial 
ranging CID. Within the RNG-RSP message shall be the Basic and Primary Management CIDs assigned to this SS. The 
message shall also contain information on RF power level adjustment and offset frequency adjustment as well as any 
timing offset corrections. At this point the BS shall start using invited Initial Ranging Intervals addressed to the SS's 
Basic CID to complete the ranging process, unless the status of the RNG-RSP message is success, in which case the 
initial ranging procedure shall end. 

If the status of the RNG-RSP message is continue, the SS shall wait for an individual Initial Ranging interval assigned 
to its Basic CID. Using this interval, the SS shall transmit another RNG-REQ message using the Basic CID along with 
any power level and timing offset corrections. 

The BS shall return another RNG-RSP message to the SS with any additional fine tuning required. The ranging 
request/response steps shall be repeated until the response contains a Ranging Successful notification or the BS aborts 
ranging. Once successfully ranged (RNG-REQ is within tolerance of the BS), the SS shall join normal data traffic in the 
uplink. In particular, state machines and the applicability of retry counts and timer values for the ranging process are 
defined in table 340 from IEEE P802. 16-2004 [1]. 

NOTE 2: The burst profile to use for any uplink transmission is defined by the Uplink Interval Usage Code 
(UIUC). Each UIUC is mapped to a burst profile in the UCD message. 

The message sequence chart (table 68) and flow charts from the reference define the ranging and adjustment process 
which shall be followed by compliant SSs and BSs . 
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Table 68: Ranging and automatic adjustment procedure 



Sponsor node 



New node 



[Time to send the Initial IVIaintenance 

interval] 

Send map containing Initial Maintenance 

IE with a broadcast CID. 



[Detect un-decodable RNG-REQ] 
Send response including Frame 
Number, Initial Ranging Opportunity 
Number, CID = 0. 



[Time to send the Initial IVIaintenance 

interval] 

Send map containing Initial Maintenance 

IE with a broadcast CID. 



[Detect decodable RNG-REQ] 
Allocate Basic and Primary Management 
CID and add Basic CID to poll list. 
Send response including SS MAC 
Address, Basic CID 



[time to send next map] 

send map with Station Management IE 

to SS using Basic CID 



Send ranging response 

Send periodic transmit opportunity to 
broadcast address 



-UL-MAP - 
RNG-REQ 

-RNG-RSP 



-UL-MAP - 
RNG-REQ 



-RNG-RSP 



-UL-MAP 



-RNG-REQ 
-RNG-RSP 



-UL-MAP 



Transmit ranging packet in contention 
mode with CID = 0. 



[Recognize Frame Number/ Opportunity 
when RNG-REQ was send] 
Adjust parameters according to RNG- 
RSP. 



Transmit ranging packet in contention 
mode with CID = 0. 



[Recognize own MAC Address] 

Store Basic CID and adjust parameters 

according to RNG-RSP. 



[Recognize own Basic CID] 

reply to Station Management opportunity 

poll. 

Adjust local parameters. 



NOTE 1 : The BS shall allow the SS sufficient time to have processed the previous RNG-RSP (i.e., to modify the 

transmitter parameters) before sending the SS a specific ranging opportunity. This is defined as SS Ranging 
Response Processing Time in table 340 from IEEE P802. 16-2004 [1]. 

NOTE 2: For multichannel support, the SS shall attempt initial ranging on every suitable uplink channel before moving 
to the next available downlink channel. 



On receiving a RNG-RSP instruction to move to a new downlink frequency and/or uplink channel ID, the SS shall 
consider any previously assigned Basic, Primary Management, and Secondary Management ClDs to be de assigned, 
and shall obtain new Basic, Primary Management, and Secondary Management ClDs via initial ranging and 
registration. 

It is possible that the RNG-RSP may be lost after transmission by the BS. The SS shall recover by timing out and 
reissuing its Initial RNG-REQ. Since the SS is uniquely identified by the source MAC address in the Ranging Request, 
the BS may immediately reuse the Basic, Primary Management, and Secondary Management CIDs previously assigned. 
If the BS assigns new Basic, Primary Management, and Secondary Management CIDs, it shall make some provision for 
aging out the old CIDs that went unused. 



£75/ 



79 ETSI TS 1 02 1 78 V1 .2.1 (2005-01 ) 



9 Periodic ranging 

Clause 6.3.10.2 from IEEE P802.16-2004 [1] shall apply to PMP systems periodic ranging. 

10 Bandwidth allocation and request mechanism 

A compliant device shall conform to bandwidth allocation and request mechanisms provided by clauses 6.3.6.1 to 
6.3.6.4 as defined in IEEE P802.16-2004 [1]. 
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